plug:iec958 problems

plug:iec958 problems

[Martin Soto]

Hi everyone!

I'm writing a DVD player application based on the GStreamer media
framework (www.gstreamer.net), and, of course, ALSA sound output should
be supported. In particular I'm trying to use the iec958 plugin to
output AC3 sound directly to an external receiver.  In principle, this
works ok, except for a little but annoying detail: when the machine is
under even moderate load, I start hearing short interruptions in the
sound.

Some investigation  of the problem makes me thing it doesn't lie in my
code, because I can trigger it as well with pure vanilla ac3dec -C. All
I need is a constant moderate load, like that generated by the DVD
reading process (in my pretty old AMD Athlon 700, this causes a load of
about 25%) and then suddenly creating a load peak, which I achieve by
quickly moving a window on my desktop. Sound output interrupts suddenly,
some times even for about half a second.

Of course, the first thing I thought was that it had something to do
with data starvation. This doesn't seem to be the case either.
Specially, it called my attention that the API isn't reporting any
buffer underruns. ac3dec doesn't either show any messages when the
problem shows up. Additionally, putting the corresponding thread or
process in SCHED_FIFO mode doesn't either help. I could, for example,
reproduce the problem while running ac3dec in SCHED_FIFO policy,
priority 99

As an additional note, this only seems to happen when using plug:iec958.
Software decoding the AC3 sound and plying through ALSA, works
flawlessly, despite of the fact that the machine load is higher.

I'm using kernel 2.6.5 with the included version of ALSA. My alsa
library is 1.0.3b, from the Debian package, and I'm testing with a
SBLive! card attached to the receiver with an optical link through a
simple third party SBLive! add-on. I have seen the same problem with 2.4
kernels, together with self-compiled recent (post 1.0) ALSA versions.

Any clue?

M. S.
-- 
Martin Soto <soto@informatik.uni-kl.de>



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

Re: plug:iec958 problems

[Takashi Iwai]

At Sat, 17 Apr 2004 22:58:57 +0200,
Martin Soto wrote:
> 
> As an additional note, this only seems to happen when using plug:iec958.
> Software decoding the AC3 sound and plying through ALSA, works
> flawlessly, despite of the fact that the machine load is higher.

is there any different if you get rid of plug: ?
as long as the h/w support 16bit LE data, AC3 should work without
plug.


Takashi


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

Re: plug:iec958 problems

[Martin Soto]

Hello Takashi!

On Tue, 2004-04-20 at 12:36, Takashi Iwai wrote:
> At Sat, 17 Apr 2004 22:58:57 +0200,
> Martin Soto wrote:
> > As an additional note, this only seems to happen when using plug:iec958.
> > Software decoding the AC3 sound and plying through ALSA, works
> > flawlessly, despite of the fact that the machine load is higher.
> 
> is there any different if you get rid of plug: ?
> as long as the h/w support 16bit LE data, AC3 should work without
> plug.

I just tested. There seems to be no difference. I tried with iec958: and
spdif: instead of plug:iec958:. The problem persists. 

As I said, putting the process in SCHED_FIFO mode doesn't make any
difference at all. Almost any machine activity (any process being active
for more than a fraction of a second) is enough to interrupt the sound.
Does the library use some auxiliary process to play through spdif?

M. S.
-- 
Martin Soto <soto@informatik.uni-kl.de>



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

Re: plug:iec958 problems

[Takashi Iwai]

At Wed, 21 Apr 2004 20:57:37 +0200,
Martin Soto wrote:
> 
> Hello Takashi!
> 
> On Tue, 2004-04-20 at 12:36, Takashi Iwai wrote:
> > At Sat, 17 Apr 2004 22:58:57 +0200,
> > Martin Soto wrote:
> > > As an additional note, this only seems to happen when using plug:iec958.
> > > Software decoding the AC3 sound and plying through ALSA, works
> > > flawlessly, despite of the fact that the machine load is higher.
> > 
> > is there any different if you get rid of plug: ?
> > as long as the h/w support 16bit LE data, AC3 should work without
> > plug.
> 
> I just tested. There seems to be no difference. I tried with iec958: and
> spdif: instead of plug:iec958:. The problem persists. 

ok, thanks for the confirmation.

> As I said, putting the process in SCHED_FIFO mode doesn't make any
> difference at all. Almost any machine activity (any process being active
> for more than a fraction of a second) is enough to interrupt the sound.
> Does the library use some auxiliary process to play through spdif?

the problem seems to be hardware-specific.  either the hardware itself
has a problem (e.g. PCI irq routing), or some driver takes the context
for too long time.

did you try the preempt kernel?  it won't solve all the cases but some
of them (the long context without spinlock).


Takashi


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click