ALSA lib pcm.c:7339:(snd_pcm_recover) underrun occurred #852
Comments
|
I also get this log. |
|
I also have that problem with build from commit SHA: 9f8d79c on x64 Gentoo. Looks like it switching back to alsa. Sound quality is bad, and sound is laggy. |
|
@Ghost99 the "cannot open" is "okay". FreeRDP has currently a fixed module load order for sound and it tries pulse even if it wasn't compiled. |
|
@bmiklautz is it the fault of rdpsnd channel thread's priority bug? since the sound data arrive, but the rdpsnd thread doesn't process immediately and put it into the alsa's buffer, see@ http://alsa.opensrc.org/Xruns |
|
@gotsiboon @ShuminHuang @Ghost99 can you try the latest git master and test if the problem is fixed for you? |
|
SHA: c581d89 |
|
@Ghost99 can you try with +async-update +async-input ? |
|
Only difference is that two of my CPU cores is now fully consumed by xfreerdp process while it is running. I'm also having a SIGSEGV with +async-update +async-input |
|
Any progress? Still exists in HEAD. |
|
@tonyhook the recent improvements to /async-input /async-update make it more bearable, but the buffer underrun still occurs, especially when initially buffering. I'm open to suggestions as to why the buffer underrun happens so easily, probably due to poor thread synchronization for the channels? |
|
@awakecoding I try to fix the problem, please have a check. Thank you. |
|
Sorry, line 422 should be: |
|
@tonyhook I applied your patch, but didn't see that much of a difference. There seems to be a lot of ways to setup alsa though, we might be other things wrong. |
|
Investigating further: when playing a video in GDI mode and the video not being shown (to get only sound, not video), 60% of the execution time is spent just in snd_pcm_writei called from rdpsnd_alsa_play |
|
I connect to a Windows Server 2008 R2 RDSH server, play mp3 file in Windows Media Player. Before apply the patch, underrun occurs much in the beginning, and less after a while. After apply the patch, no underrun occurs. CPU ultilization keeps at a low level under 2.4%. Both Fedora 16 (running xfreerdp) and Windows are VMware Workstation virtual machine, and patched up-to-date. Maybe different environment? I will test Windows XP and of course video playing later. Did you start the video playing and minimize the player window to get only sound? Thanks. |
|
@tonyhook :Thanks for your hardwork. I also can get underrun log when using VLC to play mp3 after apply your patch. I also get underrun log when setting the audio quality to DYNAMIC_QUALITY. And there are some flaw in your patch. |
|
@tonyhook I spent the last two days playing gangnam style in loop while testing sound redirection. This problem is not easily solved and it really has to do with threading & synchronization. I made major changes on my branch to refactor the way the channel is queueing and dequeuing events, making the synchronization more predictable but still similar to the original. I noticed that what makes a major difference is really the timing and values at which the Wave Confirm PDUs are sent back. What the code currently does is queue a Wave Confirm PDU for sending with a timestamp 250ms in the future. The dequeuing thread waits until that time is reached before sending it. Sending the Wave Confirm PDU ASAP simply makes it horribly skip. If you screw up the time values, the server thinks you can't handle the sound properly and starts degrading quality. Reading the spec, we're doing this wrong, and the fact that it sometimes works fine is just luck. I have no idea why a delay of 250ms seems to work best, but I tried changing it to other values and it would be worse. I didn't write the original code so I guess the logic was to emulate more or so the proper timing. Here's the part which explains the Wave Confirm PDU: There are two conditions which need to be met before sending the Wave Confirm PDU:
In other words, we need to receive the full sample, which is sent with a sequence of Wave Info PDU and Wave PDUs. We are currently queuing the Wave Confirm PDU on receipt, which does not comply with the second condition: we should be producing the Wave Confirm PDU after consuming it the audio sample! My guess is that the added 250ms delay on the timestamp somehow emulates processing the audio sample and sending the Wave Confirm PDU at the proper time. However, this is far from perfect and it just doesn't work all the time. Here's my suggestion: we need a proper asynchronous queue for audio samples, which dequeues and processes the samples when ALSA is ready to process them, and then sends the Wave Confirm PDUs. I am pretty sure this would truly solve the issue once and for good. |
|
@tonyhook oh, by the way, I'm testing with the Gangnam Style videoclip. I've made a copy of the video at different resolutions using keepvid.com. You can also get just the mp3 if you want to avoid putting additional stress with RemoteFX. |
|
@tonyhook I am now wondering if this isn't a hardware limitation up to a certain degree... I noticed we couldn't set the buffer and period size to the values we wished. Doing proper checks and setting the values to the maximum allowed by the hardware, I end up with a buffer size of 7526 and a period size of 940. The latency values we were using were pretty much ignored. As for the start threshold, it is useless: a single wave pdu contains more audio data than the buffer can hold! this means that no matter what threshold you set, playback will start as soon as you get data (unless you put a threshold higher than the buffer size, which would cause issues for obvious reasons). Result: playback starts immediately with almost no latency, and there is a very tiny window in which we can play. Could other people run the code off my branch and report what values are printed out for their card? If we have to deal with such tiny values, then the only solution I could think of would be the handle the buffering ourselves with the timestamps given by the server and introduce the delay manually before giving the audio data to ALSA. |
|
Further comments: I found out that the wave confirm pdu needs to be sent after the corresponding audio data has been played: This means we're doing it wrong for all rdpsnd ports. We need way to properly queue data as we're getting it, and send the wave confirm pdu only after it's been played. Right now we're emulating this behavior by scheduling to send a wave confirm pdu somewhere in the future, like +250ms. As for ALSA, I've tried other systems, and I don't have the tiny buffer issue I have on my main system. Could other people try my branch and tell me what the reported buffer size is? It works better when the buffer size is large, but different issues occur. I'm trying to avoid mixing problems here: Format: wBitsPerSample: 4 nChannels: 1 nSamplesPerSec: 44100 |
|
@awakecoding hi Marc, I've check outed to your branch, and tested the buffer size both on my laptop and notebook ubuntu 12.04, and got these output: |
|
@awakecoding so it seems the same with most of the latest linux systems. |
|
Sorry for response late. I just fix issue #977, opened by myself :p. Anyone can merge the fix. You are right, awakecoding, FreeRDP seems to has a wrong implementation of alsa rdpsnd channel. In the version of 0.8.2, I tried to write a Windows support using winmm libraries, the same problem. But here I'd better focus on alsa. |
|
@tonyhook I merged your fix a few days, just you pushed in your repository, and I found it won't work with your patch, there's no sound at all with alsa sound option after merging your patch. |
|
Don't apply that patch any longer, pls. I realized that it can do little for this bug. |
|
http://www.youtube.com/watch?v=JUF8xPKBQJM I got it improved on my branch, better server performance also helps |
|
I have merged my changes on master, it fixes the issue for me. Please give it a try and report back. |
|
@tonyhook yes, with that patch applied, only pulse of rdpsnd works. |
ghost
assigned
|
@tonyhook @gotsiboon do @awakecoding fixes (current git master) fix this problem? |
|
Fix: rozhuk-im@8d5825e |
|
/sound:sys:alsa,format:1,quality:high With this package: |
Hi guys,
I've got "ALSA lib pcm.c:7339:(snd_pcm_recover) underrun occurred" in todays master (FreeRDP version 1.1.0-dev (git 1.0.1-1519-g1ce9e)).
I'm using these parameters:
xfreerdp /u:user /vc:rdpsnd,sys:alsa,dev:default /mic +clipboard /workarea /v:192.168.x.x:3389
BR, gotsiboon.
The text was updated successfully, but these errors were encountered: