A few thoughts...  Just based on my work before and the few people I helped later, in my experience Samsung reuses as much as possible in similar models and I don't think the laptops are that much different (if any) with regard to sound.  So I don't think its option 1.  Option 2 is a possibility and I would still consider a fresh install. I don't know about spoofing, but if you know the quirk you think is missing you can pretty easily just create a customized kernel that applies it.  I did that originally on the Ion, again based on suggestions from Mike Polzup, before I actually went down the qemu path.  It was needed back then just to get the headphones working on the Ion, but I believe that issue is now resolved in Ubunutu.  Also, for what its worth, your brightness fix worked perfectly, so there is definitely some common aspects between these machines.

Its been a couple of years, but basically my qemu approach was 
 -Install basic qemu
 -create a new windows virtual machine
 -Place a sound file on the desktop in the WM and ensure it played
 -Create the modified qemu version to get logging
 -Launch the previously verified VM 
 -Play the sound, noting where in the log it was playing
 -Record the logging
 -Translate the verb formats
 -Play back sections to find some sort of sound
 -Reduce the verbs as much as possible after getting a section that made noise

I never needed to install the windows realtek driver as a separate step, the qemu vms always had working sound just with a default install of windows.  It seemed like it would be easy once I got the modified qemu working, but it wasn't.  Honestly if we hadn't been on covid lockdown I probably would have not had the time to finish it.  I assumed, incorrectly, that if I just recorded the verbs during boot or the verbs up to the point where I heard sound on the VM it would be easy to just replay that bit and hear something, but that never really worked smoothly.  I just assumed I did it wrong and it didn't work, but later in desperation I started just taking chunks and trying them and I happened to hit a working segment. 
 I believe that was on Sept 12, thus the name of the script.  I never really figured out why the bigger chunks didn't work.

Mike gave me the basic concept and pointed me at these two approaches for logging.  He seems to have dropped away right after that, but his approach was absolutely correct.  Because I didn't think it was working originally, I made both logging approaches work, but ultimately I used the bsd style approach for the final work because i found the output easier to work with as you can just copy and paste from stdout and the verbs needed less modification:

https://jcs.org/2018/11/12/vfio

https://github.com/Conmanx360/QemuHDADump/wiki/Setup-and-usage-of-the-program#start-of-content


If it helps, here are my very incomplete notes on making the modified qemu.  I didn't write down what I changed in common.c, but I believe it was inline with the article...


Manual Install Qemu
	
	sudo apt-get build-dep qemu
	
	Download source	https://www.qemu.org/download/#source
	tar -xvf {insert-qemu-version-here}.tar.xz
	go into folder
	
	modify common.c in hw/vfio (to output the formatted tracing)
	
	In the qemu source, you'll need to edit 
		the file pci.c located in the hw/vfio folder. Edit the value: 
		
		DEFINE_PROP_UINT32("x-intx-mmap-timeout-ms", VFIOPCIDevice, intx.mmap_timeout, 1100)
			From 1100 to 0 to prevent mmap'ing, and then also edit:
		DEFINE_PROP_BOOL("x-no-mmap", VFIOPCIDevice, vbasedev.no_mmap, false)
			From false to true to prevent it completely.

	./configure --enable-trace-backends=log --target-list=x86_64-softmmu
	make -j9
	
	sudo make install