Re: Sound skips

quoted

quoted

quoted

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/

quoted

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.

quoted

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.

quoted

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/

quoted

quoted

 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/