ivshmem receivers getting stuck at "while (header->magic != 0x11112014)" about scream HOT 9 CLOSED

That's a barrier to stop the receiver until the guest have not initialized the shared memory.
If it got stuck there it means that the guest driver have not initialized the shared memory (or that no audio is being played in the VM).

What is the size of your IVSHMEM device? Have you set the value of UseIVSHMEM registry key to be equal to that size?

from scream.

@joe-p Thank you for pointing out that the receiver requires write permission. It was required in an earlier version, but not anymore. I've updated the code to open the IVSHMEM device in read only.

from scream.

@joe-p Thank you for pointing out that the receiver requires write permission. It was required in an earlier version, but not anymore. I've updated the code to open the IVSHMEM device in read only.

Yeah I thought that was a bit weird since only read permissions were stated in the README. Glad I could at least help with that.

As for the IVSHMEM device, it is indeed 2MB, and the registry key is set

PS C:\Windows\system32> Get-ItemProperty -PATH HKLM:\SYSTEM\CurrentControlSet\Services\Scream\Options\ -Name "UseIVSHMEM"


UseIVSHMEM   : 2
PSPath       : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Scream\Options\
PSParentPath : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Scream
PSChildName  : Options
PSDrive      : HKLM
PSProvider   : Microsoft.PowerShell.Core\Registry

I did notice, however, that the modify time is not changing on /dev/shm/scream-ivshmem. The access time is updating when it's getting opened by the receiver, but the contents are staying the same. For example, I started my VM this morning and have a 10 hour YouTube video playing. I have the "Scream (WDM)" speaker selected (and it's "outputting" sound according the volume mixer), yet the last modify was last night. I would assume the expected behavior is the file being written to by the Windows driver.

Also, for my own sanity, I added a timeout counter that displays a debug message every three seconds while the program is in this while loop. Might be useful to implement in case anyone else has a similar issue so they aren't just staring at a blank prompt.

from scream.

May I ask you to post the hex dump of the shared memory header while the VM is playing something?

If you have xxd this is the command: xxd -l 100 /dev/shm/scream-ivshmem

Thanks

from scream.

Just to confirm this, are you running version 3.2?

from scream.

Yes, on windows I downloaded the 3.2 zip from the release page and on the host I just cloned the repo (last night, so effectively 3.2). I now also pulled the read/write changes on the host.

The header seems to be all zeros while spotify is playing on the VM. Last modify time for /dev/shm/scream-ivshmem is still last night (I'm in EST, so about 10 hours ago).

[joe@localhost pulseaudio-ivshmem]$ xxd -l 100 /dev/shm/scream-ivshmem
00000000: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000010: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000020: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000030: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000040: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000050: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000060: 0000 0000                                ....

from scream.

In windows, have you also installed the IVSHMEM driver from here ?

I think we need to update the readme on this.

That hex dump shows that not only the shared memory is not initialized, but no sound was ever wrote in it.

from scream.

Ah... yep, that was it. After installing the driver and restarting the VM audio works great.

from scream.

@joe-p thanks for reporting that it's working now :)

@duncanthrax when you have time can you update the readme to remember users to install the IVSHMEM driver from the link above?

from scream.