[alsa-devel] PCM multi A/V Sync bug on SMP system
Hi
I have a SB Audigy Value card with 5.1 channel output. This is defined in my asound.conf: --------------------------- pcm.multi { type multi slaves { a.pcm "dmixerrear" a.channels 2 b.pcm "dmixerfront" b.channels 2 c.pcm "dmixercenter" c.channels 2 } bindings { 0.slave a 0.channel 0 1.slave a 1.channel 1 2.slave b 2.channel 0 3.slave b 3.channel 1 4.slave c 4.channel 0 5.slave c 5.channel 1 } }
pcm.dmixerfront { type dmix ipc_key 1024 slave { pcm "hw:0,0" channels 2 } }
pcm.dmixerrear { type dmix ipc_key 1025 slave { pcm "hw:0,1" channels 2 } } pcm.dmixercenter { type dmix ipc_key 1026 slave { pcm "hw:0,2" channels 2 } } ---------------------------
Playing a video with "mplayer -ao alsa:device=multi ..." works fine, I can hear the 6-channel audio without any A/V sync issues. However, this is on a uniprocessor system. On an SMP system, the A/V sync gets out of sync from the start and drifts quite quickly.
I have narrowed it down to the pcm_multi component giving this problem. On an SMP system, using just "mplayer -ao alsa ..." gives no A/V sync issues (because it is not using multi) on the 6 channels. Moreover, I have also tried "mplayer -ao alsa:device=dmixerfront ...", "mplayer -ao alsa:device=dmixercenter ..." and "mplayer -ao alsa:device=dmixerrear ...", all giving no A/V sync issues on the individual devices.
Please advise how can I track down this problem in code, happy to make changes and test.
PS: I need multi to work, so that I can add additional options like softvol on top of it.
Regards Keith
Please advise how can I track down this problem in code, happy to make changes and test.
After further investigation on the soucecode, it appears that the default surround51 for the driver ca0106, uses "multi" to the 3 devices/outputs on the card. So "multi" does work fine on an SMP system. The timing problems are only introduced when "multi" is combined with "dmix" for 5.1 channels.
I would like to help out in fixing this, but need a little bit of guidance from the experts here. Have I identified the problem correctly? Ie interaction between "multi" and "dmix" on a 5.1 channel card giving timing issues on an SMP system? If it is unlikely, I will investigate other areas.
Regards Keith
I would like to help out in fixing this, but need a little bit of guidance from the experts here. Have I identified the problem correctly? Ie interaction between "multi" and "dmix" on a 5.1 channel card giving timing issues on an SMP system? If it is unlikely, I will investigate other areas.
Ok, I don't seem to be getting much help from this mailing list, so I have dug deeper into the code, and found the problem. In pcm_dmix_i386.c, we have:
if (!strncmp(line, "processor", 9)) smp++;
I have commented out the smp++, so that it thinks that I am on a uni processor. Voila, so AV sync issues!
My question now is what are the implications of this change? Looking at pcm_dmix_i386.h, it uses locks on an SMP system, but exclude them if not SMP. Do we still need this lock, even if I am on a dual core, ie 1 processor 2 cores?
I have CC'ed the author of the file, Jaroslav Kysela.
Regards Keith
Keith Chew wrote:
In pcm_dmix_i386.c, we have:
if (!strncmp(line, "processor", 9)) smp++;I have commented out the smp++, so that it thinks that I am on a uni processor. Voila, so AV sync issues!
My question now is what are the implications of this change? Looking at pcm_dmix_i386.h, it uses locks on an SMP system, but exclude them if not SMP. Do we still need this lock, even if I am on a dual core, ie 1 processor 2 cores?
Dual-core processors behave like two separate processors, i.e., they still have separate caches, so we still need to synchronize memory accesses to ensure that they happen in the correct order.
I'd guess that the memory bus synchronization of the three dmix devices makes the memory accesses too slow. What is the CPU utilization of mplayer with and without SMP?
Regards, Clemens
participants (2)
-
Clemens Ladisch -
Keith Chew