Sound skips

Sound skips

[Giuliano Pochini]

When I play music under high load the sound has a lot of
short interruptions. It seems not to be related with I/O. I tried
Alsaplayer and xmms with OSS output. Xmms with esd is better but
not perfect. Xmms uses a buffer of 2KB but I had to patch it to
use a 8KB large one to make it play fine on my G3, but it still
jumps sometimes on the G4.
This happend on my G3 and a friend's G4(2000).
I don't remember my 7300 had this problem.

I don't know what causes that (ints kept disabled too much time ?)
but if someone has a patch to try I'me here.

Bye.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Sound skips

[Iain Sandoe]

> When I play music under high load the sound has a lot of
> short interruptions. It seems not to be related with I/O. I tried
> Alsaplayer

this is with Takashi Iwai's driver (it's the only one AFAIK)

>and xmms with OSS output. Xmms with esd is better but
> not perfect. Xmms uses a buffer of 2KB but I had to patch it to
> use a 8KB large one to make it play fine on my G3, but it still
> jumps sometimes on the G4.
> This happend on my G3 and a friend's G4(2000).
> I don't remember my 7300 had this problem.

which OSS driver are you using?
dmasound?
with or without my patches?

> I don't know what causes that (ints kept disabled too much time ?)
> but if someone has a patch to try I'me here.

there are a variety of things that can block for between 16 & 300 ms (not
necessarily IRQs).

what size fragments are you using?

ciao,
Iain.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Sound skips

[Giuliano Pochini]

Iain Sandoe wrote:
>
> > When I play music under high load the sound has a lot of
> > short interruptions. It seems not to be related with I/O. I tried
> > Alsaplayer
>
> this is with Takashi Iwai's driver (it's the only one AFAIK)
>
[...]
>
> which OSS driver are you using?
> dmasound?

Yes.

> with or without my patches ?

Plain 2.4.2. I'm d/l-ing your patches now. I'll let you know.

> > I don't know what causes that (ints kept disabled too much time ?)
> > but if someone has a patch to try I'me here.
>
> there are a variety of things that can block for between 16 & 300 ms (not
> necessarily IRQs).
>
> what size fragments are you using?

2K. I have to rise it to 8KB to work fine. My friend with the G4 still have
very few interruptions even with 8KB.

Bye.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Sound skips

[Iain Sandoe]

>> there are a variety of things that can block for between 16 & 300 ms (not
>> necessarily IRQs).
>>
>> what size fragments are you using?
>
> 2K. I have to rise it to 8KB to work fine. My friend with the G4 still have
> very few interruptions even with 8KB.

OK.... if you can't do with such large fragments ....

 You might want to try Andrew Morton's Low-Latency patch (URL:
 http://www.uow.edu.au/~andrewm/linux/schedlat.html#downloads )

it makes things quite a lot better - but we still have a way to go on PPC
before we can achieve sub-ms block-free operation.  Another thing on the
audio TODO list ;-)

let me/us know how you do if you try it (last time I did, the patches
applied cleanly to the PPC BK tree) - you (could at the time) ignore the
x86-specific mods to head.S.

HTH,
Iain.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Sound skips

[Giuliano Pochini]

>>> there are a variety of things that can block for between 16 & 300 ms (not
>>> necessarily IRQs).
>>>
>>> what size fragments are you using?
>>
>> 2K. I have to rise it to 8KB to work fine. My friend with the G4 still have
>> very few interruptions even with 8KB.
>
> OK.... if you can't do with such large fragments....
>
>  You might want to try Andrew Morton's Low-Latency patch (URL:
>  http://www.uow.edu.au/~andrewm/linux/schedlat.html#downloads )

Ok, I'll try, but this problem regards interrupt latency, not user-space latency.

In the meantime I applied your patch (ints << 10 can't compile
in _core.c and I had to comment them out). It makes no difference.
I was fiddling compiling things and I noticed that one of the
worst offenders is libtool, a script in the root the the xmms source tree. Just
run it to get a 100ms pause. This night I'll check if rt_sigprocmask() keeps
irq disabled. Another thing is console scrolling.


Bye.
    Giuliano Pochini ->)|(<- Shiny Network {AS6665} ->)|(<-


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Sound skips

[Iain Sandoe]

>>>> there are a variety of things that can block for between 16 & 300 ms (not
>>>> necessarily IRQs).
>>>>
>>>> what size fragments are you using?
>>>
>>> 2K. I have to rise it to 8KB to work fine. My friend with the G4 still have
>>> very few interruptions even with 8KB.
>>
>> OK.... if you can't do with such large fragments....
>>
>>  You might want to try Andrew Morton's Low-Latency patch (URL:
>>  http://www.uow.edu.au/~andrewm/linux/schedlat.html#downloads )
>
> Ok, I'll try, but this problem regards interrupt latency,
> not user-spacelatency.

can you be sure it is IRQ and not scheduling latency?  If so, can you
identify what driver or function is holding off IRQs for this length of
time? [a few hundred ms is a 'monstrous' time to hold IRQs off].

Andrew's ll patch addresses scheduling latency - i.e. processes
blocked from running by other processes executing lengthy jobs in system
state.  For example, fs work done by the kernel on behalf of user processes.

That is, it's not about IRQ latency or "User-state" latency ... but
"system-state" latency.

> In the meantime I applied your patch (ints << 10 can't compile
> in _core.c and I had to comment them out).

I'll take a look at this.

>It makes no difference.

OK, that is not too much a surprise given the effects you are seeing.

> I was fiddling compiling things and I noticed that one of the
> worst offenders is libtool, a script in the root the the xmms source tree.
> Just
> run it to get a 100ms pause. This night I'll check if rt_sigprocmask() keeps
> irq disabled.

When I last checked it, disk activity was likely to give up to 300 ms
blocks.  So, the particular culprit (in terms of applications) might be a
bit misleading - it possibly depends more on how often the buffer cache
is hit/missed.

Also, if you are IDE-based, make sure that you've used hdparm to allow
interrupts on during PIO - this makes a huge difference (especially with
CDROMs).

>Another thing is console scrolling.

yes, console *is/was* bad. - but I read a message going past on Linux Audio
Dev between Cort & AM that suggested this particular problem had been
resolved...

 http://www.uow.edu.au/~andrewm/linux/console.html

I'm not fully up-to-date with the state of the LL patches... I'd be
interested to hear any results you get.

ciao,
Iain.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Sound skips

[Giuliano Pochini]

>> Ok, I'll try, but this problem regards interrupt latency,
>> not user-spacelatency.
>
> can you be sure it is IRQ and not scheduling latency?

No, but it's likely to be. The audio buffer is 32 fragments (2KB),
that is 1.48s. I don't think an app can remain blocked so long and it
doesn't explain why libtool blocks the sound since it executes in much
less time than one second.

> If so, can you
> identify what driver or function is holding off IRQs for this length of
> time? [a few hundred ms is a 'monstrous' time to hold IRQs off].

Console scrolling does it IFAIK, but this is not the case.

> Andrew's ll patch addresses scheduling latency - i.e. processes
> blocked from running by other processes executing lengthy jobs in system
> state.  For example, fs work done by the kernel on behalf of user processes.

I'll try it.

>> I was fiddling compiling things and I noticed that one of the
>> worst offenders is libtool, a script in the root the the xmms source tree.
>> Just
>> run it to get a 100ms pause. This night I'll check if rt_sigprocmask() keeps
>> irq disabled.
>
> When I last checked it, disk activity was likely to give up to 300 ms
> blocks.  So, the particular culprit (in terms of applications) might be a
> bit misleading - it possibly depends more on how often the buffer cache
> is hit/missed.

This is not the case: libtool doesn't hit the disk.

> Also, if you are IDE-based, make sure that you've used hdparm to allow
> interrupts on during PIO - this makes a huge difference (especially with
> CDROMs).

Nope. All SCSI.

>>Another thing is console scrolling.
>
> yes, console *is/was* bad. - but I read a message going past on Linux Audio
> Dev between Cort & AM that suggested this particular problem had been
> resolved...
>
>  http://www.uow.edu.au/~andrewm/linux/console.html
>
> I'm not fully up-to-date with the state of the LL patches... I'd be
> interested to hear any results you get.

Ok.

Bye.
    Giuliano Pochini ->)|(<- Shiny Network {AS6665} ->)|(<-


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Sound skips

[Iain Sandoe]

[Geert, Cort - the question for you guys is "has the Console IRQ block been
solved?" - I was under the impression it had from some traffic on
Linux-audio-dev]

Mon, Mar 26, 2001,  Giuliano Pochini wrote:
>>> Ok, I'll try, but this problem regards interrupt latency,
>>> not user-spacelatency.
>> can you be sure it is IRQ and not scheduling latency?
> No, but it's likely to be. The audio buffer is 32 fragments (2KB),
> that is 1.48s. I don't think an app can remain blocked so long

an FB scroll would block my G3/beige for 1.9 sec! (but YMMV).

>and it
> doesn't explain why libtool blocks the sound since it executes in much
> less time than one second.

no it doesn't... hmmm interesting... but see below:

--

for dmasound: regardless of how many fragments are buffered only two (max)
will be queued for dbdma - so IRQs blocked for longer than 23-ish ms will
skip with that setup.

[the IRQ routine deals with queuing fragments written by the app but not yet
 queued for dbdma]

In addition - unless the app can write all 32 fragments ahead - if *it* is
blocked (by scheduling latency) this will also cause the same effects.

>> If so, can you
>> identify what driver or function is holding off IRQs for this length of
>> time? [a few hundred ms is a 'monstrous' time to hold IRQs off].
> Console scrolling does it IFAIK, but this is not the case.

Yes, console is/was a bad offender - but I thought that the IRQ block in
that had been solved...

Cort? Geert?

ciao,
Iain.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Sound skips

[Geert Uytterhoeven]

On Mon, 26 Mar 2001, Iain Sandoe wrote:
> [Geert, Cort - the question for you guys is "has the Console IRQ block been
> solved?" - I was under the impression it had from some traffic on
> Linux-audio-dev]

According to Andrew Morton it is. That's all I can say :-)

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Sound skips

[Giuliano Pochini]

> >>  You might want to try Andrew Morton's Low-Latency patch (URL:
> >>  http://www.uow.edu.au/~andrewm/linux/schedlat.html#downloads)

Done. It doen't make a lot difference, but I can compile stuff without
sound interruptions most of the time (if it doesn't involve libtool).
I tried to lower the fragment size to 9 (512B==0.012s) and it skips
even when the system is completely idle.


Bye.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Sound skips

[Iain Sandoe]

>> >>  You might want to try Andrew Morton's Low-Latency patch (URL:
>> >>  http://www.uow.edu.au/~andrewm/linux/schedlat.html#downloads)
>
> Done. It doen't make a lot difference, but I can compile stuff without
> sound interruptions most of the time

OK.  So nothing much has changed since I last tried it - note that those
patches take scheduling latency below 1ms on x86.

maybe we do have some IRQ blocking as well (I haven't had time to benchmark
that at 2.4.x - it's on the TODO list).

>(if it doesn't involve libtool).

hmmm.  Have you got any idea what libtool does that is different?
(does strace work at the moment?)

mmap-ing files is "bad news" even with the LL patches (IIRC).

> I tried to lower the fragment size to 9 (512B==0.012s) and it skips
> even when the system is completely idle.

I don't know what UI you are using but...

does this occur each second (i.e. related to, for example, updating a clock
on screen) ... or

every 20/30 seconds or so - perhaps related to sync() ?

---

ah well, we'll solve it eventually [otherwise PPC is dead for sound - which
would be a Great Shame (tm).]

ciao,
Iain.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Sound skips

[Giuliano Pochini]

> OK.  So nothing much has changed since I last tried it - note that those
> patches take scheduling latency below 1ms on x86.

This means the bad code is in the "small" arch-dependdent part
of the kernel.

> maybe we do have some IRQ blocking as well (I haven't had time to benchmark
> that at 2.4.x - it's on the TODO list).
>
>>(if it doesn't involve libtool).
>
> hmmm.  Have you got any idea what libtool does that is different ?

Not yet. I'll look for it ASA I have time.

> (does strace work at the moment?)

Yes it does. The only uncommon thing I can see is a huge number of
calls to rt_sigprocmask().

> mmap-ing files is "bad news" even with the LL patches (IIRC).

I didn't know that.

>> I tried to lower the fragment size to 9 (512B==0.012s) and it skips
>> even when the system is completely idle.
>
> I don't know what UI you are using but...

I wrote a small prog to play aiffs from disk.

> does this occur each second (i.e. related to, for example, updating a clock
> on screen) ... or
>
> every 20/30 seconds or so - perhaps related to sync() ?

I don't know... It seems quite random, but I have some stuff running in
the taskbar. I'll check better.


Bye.
    Giuliano Pochini ->)|(<- Shiny Network {AS6665} ->)|(<-


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Sound skips

[Giuliano Pochini]

> >(if it doesn't involve libtool).
>
> hmmm.  Have you got any idea what libtool does that is different ?
> (does strace work at the moment?)

The only unusual thing strace shows is thai it calls rt_sigprocmask()
hundred times. rt_sigprocmask() stops irqs for a very short time. A
prog that calls it 1M time shows this is not what I'm looking for.
I searched in all /arch/ppc for something interesting... nothing. I
definitely need a tool to measure how much time the various
spinlock_irq's are hold.

> mmap-ing files is "bad news" even with the LL patches (IIRC).

strace libtool shows 13 lines like this:

mmap(ptrace: umoven: input/output error
)                                  = 0x30019000

I don't know what does it mean.

Bye.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Sound skips

[Iain Sandoe]

Note: this is a completely *different* problem from the PowerComputing
"DEAD" dbdma one...

This problem exist for _all_ PPC Linux users - and _did_ exist for all x86
users (without) applying Andrew Morton's LL patches.

Perhaps I'll ask Andrew about libtool (it may still give hassles on x86).

If you look at my latest patches they log overruns (reported as xrun in
/dev/sndstat output).

I get *lots* on all my systems (without LL patches) even when lightly
loaded.

>> >(if it doesn't involve libtool).
>>
>> hmmm.  Have you got any idea what libtool does that is different ?
>> (does strace work at the moment?)
>
> The only unusual thing strace shows is thai it calls rt_sigprocmask()
> hundred times. rt_sigprocmask() stops irqs for a very short time. A
> prog that calls it 1M time shows this is not what I'm looking for.
> I searched in all /arch/ppc for something interesting... nothing. I
> definitely need a tool to measure how much time the various
> spinlock_irq's are hold.

Well, I did something for 2.2.x - maybe I'll try and re-do this soon for
2.4.x.

>> mmap-ing files is "bad news" even with the LL patches (IIRC).
>
> strace libtool shows 13 lines like this:
>
> mmap(ptrace: umoven: input/output error
> )                                  = 0x30019000
>
> I don't know what does it mean.

Me neither... (exactly) - but maybe it's the problem  ;-)

ciao,
Iain.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Sound skips

[Giuliano Pochini]

> Note: this is a completely *different* problem from the PowerComputing
> "DEAD" dbdma one...

Yes, the subject of the message is different too :))

> This problem exist for _all_ PPC Linux users - and _did_ exist for all x86
> users (without) applying Andrew Morton's LL patches.

I didn't noticed the problem on my father's x86, but I'm not
sure. I'll try ASAP.

> Perhaps I'll ask Andrew about libtool (it may still give hassles on x86).

libtool is a bash script.

> If you look at my latest patches they log overruns (reported as xrun in
> /dev/sndstat output).
>
> I get *lots* on all my systems (without LL patches) even when lightly
> loaded.

sndstat ? I didn't looked at that.

>
>>> >(if it doesn't involve libtool).
>>>
>>> hmmm.  Have you got any idea what libtool does that is different ?
>>> (does strace work at the moment?)
>>
>> The only unusual thing strace shows is thai it calls rt_sigprocmask()
>> hundred times. rt_sigprocmask() stops irqs for a very short time. A
>> prog that calls it 1M time shows this is not what I'm looking for.
>> I searched in all /arch/ppc for something interesting... nothing. I
>> definitely need a tool to measure how much time the various
>> spinlock_irq's are hold.
>
> Well, I did something for 2.2.x - maybe I'll try and re-do this soon for
> 2.4.x.

I'll try to write a replacement for spin_*lock_irq* to make use of
time base facility to measure times. The problem is I don't know
how to store and export the data so all the kernel can see it. I have
to write a nice /proc interface too. It could take a lot of time...


Bye.
    Giuliano Pochini ->)|(<- Shiny Network {AS6665} ->)|(<-


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Sound skips

[Iain Sandoe]

Hi Giuliano,
>> Note: this is a completely *different* problem from the PowerComputing
>> "DEAD" dbdma one...
>
> Yes, the subject of the message is different too :))

sorry... (don't send mail when tired Iain.. ;-) [there are two threads one
named "sound stoppage" & one named "sound skips"...]

>> This problem exist for _all_ PPC Linux users - and _did_ exist for all x86
>> users (without) applying Andrew Morton's LL patches.
>
> I didn't noticed the problem on my father's x86, but I'm not
> sure. I'll try ASAP.

well, it is widely reported on Linux Audio Dev (and the motivation behind
much debate about the right method to cure it on lkml)...

>> Perhaps I'll ask Andrew about libtool (it may still give hassles on x86).
> libtool is a bash script.
but it must be calling something that does the damage - maybe whatever it
calls still does damage on x86.  (unless it's bash itself)...

>> If you look at my latest patches they log overruns (reported as xrun in
>> /dev/sndstat output).
>>
>> I get *lots* on all my systems (without LL patches) even when lightly
>> loaded.
>
> sndstat ? I didn't looked at that.

I'd be interested to see the output of /dev/sndstat when you are running
your tests...

>>
>>>> >(if it doesn't involve libtool).
>>>>
>>>> hmmm.  Have you got any idea what libtool does that is different ?
>>>> (does strace work at the moment?)
>>>
>>> The only unusual thing strace shows is thai it calls rt_sigprocmask()
>>> hundred times. rt_sigprocmask() stops irqs for a very short time. A
>>> prog that calls it 1M time shows this is not what I'm looking for.
>>> I searched in all /arch/ppc for something interesting... nothing. I
>>> definitely need a tool to measure how much time the various
>>> spinlock_irq's are hold.
>>
>> Well, I did something for 2.2.x - maybe I'll try and re-do this soon for
>> 2.4.x.
>
> I'll try to write a replacement for spin_*lock_irq*

are you on an SMP machine?

there's a lot more that needs intercepting than that... unfortunately..

>to make use of
> time base facility to measure times.

OK - if you look at www.drfruitcake.com/linux/linuxppc.html there's a link
to the 2.2.x IRQ blocking monitor code...

>The problem is I don't know
> how to store and export the data so all the kernel can see it.

this exports the line & file of each point that does a cli/sti etc. etc.

>I have
> to write a nice /proc interface too. It could take a lot of time...

which is why I haven't re-done it yet... ;-)
(although the version before used access to a kernel memory area - which was
simpler)...

ciao,
Iain.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/