PCM multi A/V Sync bug on SMP system

PCM multi A/V Sync bug on SMP system

[Keith Chew]

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

Re: PCM multi A/V Sync bug on SMP system

[Keith Chew]

>
> 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

Re: PCM multi A/V Sync bug on SMP system

[Keith Chew]

> 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

Re: PCM multi A/V Sync bug on SMP system

[Clemens Ladisch]

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