latency timer

latency timer

[Robert Brückmann]

Hi!

I wanted to use two RME hammerfalls to record 48 channels of audio via adat,
do some signal processing and play them back again. But I experienced a very
poor performance of my computer (dual pentium III 1.3GHz, 512MB RAM). It
wasn't even able to record 48 channels without xruns.

I modified aplay/arecord that it plays/records more than 32 channels (btw:
why did the developers insert such a silly check which didn't allow more
than 32 channels???), but arecord gave many xruns while recording (aplay
worked fine):

arecord --device="rme9652_dual32" --format=S_32LE --rate=44100 --channels=48

rme9652_dual_32 is a device defined in ~/.asoundrc.

I found out that increasing the latency timer in my BIOS helped out (I
increased it from 0x20 to 0x30), but if the computer gets too much xruns
after another, it locks.

Does anyone know, what the latency timer actually does? It affected the
performance of the cards rapdily. But what is the disadvantage of increasing
that value? Should I set it to maximum (0x80)?

Thanks,
Robert

BTW: Might the low latency check help with my problem?




_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: latency timer

[Paul Davis]

>I wanted to use two RME hammerfalls to record 48 channels of audio via adat,
>do some signal processing and play them back again. But I experienced a very
>poor performance of my computer (dual pentium III 1.3GHz, 512MB RAM). It
>wasn't even able to record 48 channels without xruns.
>
>I modified aplay/arecord that it plays/records more than 32 channels (btw:
>why did the developers insert such a silly check which didn't allow more
>than 32 channels???), but arecord gave many xruns while recording (aplay
>worked fine):

arecord *CANNOT* do this. it is not designed to do serious multitrack
recording. you will never get it to work unless you have a disk
subsystem with unbelievable seek and sustained i/o performance. if
arecord could do this, the work that i've put into ardour over the
last couple of years would be (partly) a waste of time. you can't
stream that much data to disk in real time without a multithreaded
design, which arecord does not have.

i doubt that arecord could go much above 12 channels with its
single-threaded design, certainly if using 32 bit samples.

>BTW: Might the low latency check help with my problem?

i presume you are referring to the low latency patch. it is only of
critical if you are using low period sizes, which for recording 48
tracks is not the optimal setting. however, it can help any audio
program, even xmms and the like.

--p


_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: latency timer

[Robert Brückmann]

Paul,

if I set the latency timer to 0x30, I am able to stream 48 channels of data
to a speed-optimized raid system. However this is not the point. The arecord
command was just an example, the computer has severe problems to record and
play data with 48 channels in realtime if I don't increase the latency timer
(even without streaming to disk, but only to memory). Do you know what the
pci-latency timer does actually?

My system locks too often when doing that. I posted the code I used several
days before, but there was no answer. I just want to know, if other
programmers would do it the same way, or if I'm missing an important point.

Robert


----- Original Message -----
From: "Paul Davis" <pbd@op.net>
To: "Robert Br ckmann" <robert.brueckmann@stud.tu-ilmenau.de>
Cc: <alsa-devel@lists.sourceforge.net>
Sent: Tuesday, February 26, 2002 11:27 PM
Subject: Re: [Alsa-devel] latency timer


> >I wanted to use two RME hammerfalls to record 48 channels of audio via
adat,
> >do some signal processing and play them back again. But I experienced a
very
> >poor performance of my computer (dual pentium III 1.3GHz, 512MB RAM). It
> >wasn't even able to record 48 channels without xruns.
> >
> >I modified aplay/arecord that it plays/records more than 32 channels
(btw:
> >why did the developers insert such a silly check which didn't allow more
> >than 32 channels???), but arecord gave many xruns while recording (aplay
> >worked fine):
>
> arecord *CANNOT* do this. it is not designed to do serious multitrack
> recording. you will never get it to work unless you have a disk
> subsystem with unbelievable seek and sustained i/o performance. if
> arecord could do this, the work that i've put into ardour over the
> last couple of years would be (partly) a waste of time. you can't
> stream that much data to disk in real time without a multithreaded
> design, which arecord does not have.
>
> i doubt that arecord could go much above 12 channels with its
> single-threaded design, certainly if using 32 bit samples.
>
> >BTW: Might the low latency check help with my problem?
>
> i presume you are referring to the low latency patch. it is only of
> critical if you are using low period sizes, which for recording 48
> tracks is not the optimal setting. however, it can help any audio
> program, even xmms and the like.
>
> --p
>
>


_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: latency timer

[Paul Davis]

>if I set the latency timer to 0x30, I am able to stream 48 channels of data
>to a speed-optimized raid system. However this is not the point. The arecord
>command was just an example, the computer has severe problems to record and
>play data with 48 channels in realtime if I don't increase the latency timer
>(even without streaming to disk, but only to memory). Do you know what the
>pci-latency timer does actually?

for the BX or GX chipsets, it defines the number of PCI clocks a PCI
master (like the hammerfall) can own on the bus after the PCI central
arbiter removes the grant signal. recommended setting on my MB is 64.

>My system locks too often when doing that. I posted the code I used several
>days before, but there was no answer. I just want to know, if other
>programmers would do it the same way, or if I'm missing an important point.

well, you posted a chunk of code, not the whole thing. 

look, i've been recording huge chunks of data from a hammerfall for a
couple of years, and my code is all out there for people to look
at. i've even written JACK (with some help) to simplify the issue of
writing such applications. no, i wouldn't do what you're doing. i
wouldn't use the read/write API, for a start.

i have never used the ALSA "multi" PCM devices, so i can't comment on
how well they will work either. its possible that they add some
additional performance penalty that affects you.

i've never recorded more than 26 channels, but i've done that *to
disk* using less than 30% of the available CPU with no xruns in sight
at the lowest period size. i also regularly run jackd in
all-input-monitor mode, copying data for all 26 channels, and that
doesn't consume more than 10-15% of the available CPU. this is on a
dual PII-450.

there is absolutely no reason to be messing around with the PCI bus
settings to do multitrack recording.

--p


_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: latency timer

[Paul Davis]

>if I set the latency timer to 0x30, I am able to stream 48 channels of data
>to a speed-optimized raid system. However this is not the point. The arecord

i would also mention that you may have potential problems doing this
with word-clock synced interfaces. its likely that they will generate
interrupts sufficiently close in time that you could be severely
stressing the full compliance of the PCI interrupt detect/CPU notify
system. basically, each card is going to reach the interrupt point at
almost exactly the same time, and this could cause problems even
though it theoretically should not (the APIC should buffer the 2nd
interrupt while the first is processed).

i would be very suprised if even RME have tried this experiment: I
don't think ASIO has any way to link two physical devices together in
the way that ALSA permits. i may be wrong about that.

--p


_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: latency timer

[Robert Brückmann]

> look, i've been recording huge chunks of data from a hammerfall for a
> couple of years, and my code is all out there for people to look
> at. i've even written JACK (with some help) to simplify the issue of
> writing such applications. no, i wouldn't do what you're doing. i
> wouldn't use the read/write API, for a start.
>
> i have never used the ALSA "multi" PCM devices, so i can't comment on
> how well they will work either. its possible that they add some
> additional performance penalty that affects you.

So what do think I should use instead? I need all 48 channels in perfect
sync (sample-accurate). Do you think that's impossible? The CPU-load of my
application is (with signal processing) less than 30%, but still there are
xruns sometimes. It might be that the pci bus can't handle my data.

>
> i've never recorded more than 26 channels, but i've done that *to
> disk* using less than 30% of the available CPU with no xruns in sight
> at the lowest period size. i also regularly run jackd in
> all-input-monitor mode, copying data for all 26 channels, and that
> doesn't consume more than 10-15% of the available CPU. this is on a
> dual PII-450.
>

If I run my program with only one hammerfall, then the CPU load is less than
10%, no xruns at all. Maybe the problem is not the 48 channels but the
syncing of the two hammerfalls.

> there is absolutely no reason to be messing around with the PCI bus
> settings to do multitrack recording.
>

But if the pci-bus is overloaded with the data it has to handle? It's a fact
that it worked only since I increased the pci-latency timer in the BIOS. I
am used to have these pci-performance problems with hardware from creamware
(under win98 however, but it was hardware-related), these cards needed a lot
of pci-bandwidth, too.
I wonder if I'm the first one who wants to use two hammerfalls in linux for
recording and playback at the same time.
Anyone?

Robert


_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: latency timer

[Robert Brückmann]

> i would also mention that you may have potential problems doing this
> with word-clock synced interfaces. its likely that they will generate
> interrupts sufficiently close in time that you could be severely
> stressing the full compliance of the PCI interrupt detect/CPU notify
> system. basically, each card is going to reach the interrupt point at
> almost exactly the same time, and this could cause problems even
> though it theoretically should not (the APIC should buffer the 2nd
> interrupt while the first is processed).
> 
> i would be very suprised if even RME have tried this experiment: I
> don't think ASIO has any way to link two physical devices together in
> the way that ALSA permits. i may be wrong about that.

So do you mean there is another way of synchronizing the cards?


_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: latency timer

[Paul Davis]

>> i would also mention that you may have potential problems doing this
>> with word-clock synced interfaces. its likely that they will generate
>> interrupts sufficiently close in time that you could be severely
>> stressing the full compliance of the PCI interrupt detect/CPU notify
>> system. basically, each card is going to reach the interrupt point at
>> almost exactly the same time, and this could cause problems even
>> though it theoretically should not (the APIC should buffer the 2nd
>> interrupt while the first is processed).
>> 
>> i would be very suprised if even RME have tried this experiment: I
>> don't think ASIO has any way to link two physical devices together in
>> the way that ALSA permits. i may be wrong about that.
>
>So do you mean there is another way of synchronizing the cards?

no. what i meant was that running two cards in sync might cause
problems like this. it would depend on the quality of the APIC
implementation and it might also depend on the kernel. maybe even the
drivers, i'm not sure. 

whatever mechanism is used to sync them, if they truly are in sync
they will be generating interrupts at almost precisely the same moment
in time, all the time.

i would check with RME that they have actually attempted to use
multiple synchronized cards in a Windows or MacOS system before
beating yourself (and myself :) up too much over this.

--p


_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: latency timer

[Paul Davis]

>So what do think I should use instead? I need all 48 channels in perfect
>sync (sample-accurate). Do you think that's impossible? The CPU-load of my

I think it might be very difficult if it involves two separate
cards. It would be easy on one card, for sure.

>application is (with signal processing) less than 30%, but still there are
>xruns sometimes. It might be that the pci bus can't handle my data.

unlikely. its less than 18MB/sec. the PCI bus can easily handle that.

>I wonder if I'm the first one who wants to use two hammerfalls in linux for
>recording and playback at the same time.

under linux: almost certainly.
under any OS: quite possibly.

one other question: what kind of video interface are you using and
which version of XFree86?

--p

_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel