Subject: Re: [ecasound] Consistent buffer overrun problem (?)
From: Mikko Nummelin (mnummeli_AT_cc.hut.fi)
Date: Fri Feb 27 2004 - 12:34:24 EET
On Fri, 27 Feb 2004, Kai Vehmanen wrote:
> On Thu, 26 Feb 2004, Arno van Amersfoort wrote:
>> Ok. I already had a feeling that I had something to do with that. But
>> what I don't understand is why does it get better when I increase the
>> buffersize? I'd expect that changing the buffersize shouldn't make a
>> difference then...
> Buffersize defines the processing cycle (both for ecasound engine and
> soundcard drivers). Let's say you have a buffersize of 23ms (-b:1024 at
> 44100Hz), and the difference between fastest and slowest soundcard clock
> is 5%. This means that on every cycle, the difference between the cards
> increases by 1ms. After 23 rounds, the fastest card will run totally out
> of data and you will get an xrun error.
> Now if the buffer size is -b:4096 -> 93ms, then it will take four times
> more time for the xrun to occur.
For future soundcard hardware design, there would be nice to have two more
parts, (A) sychronization jumper, (B) two synchronization cable plugs. It
would work as follows:
------ OFF
|
------ ON
|
------ ON
|
------ ON
Soundcards are attached to each other with syncronization cables. One of
soundcard has synchronization jumper OFF, others have it ON. This means
that if a card has the jumper OFF, it relies solely to its own clock. If a
card has the jumper ON, it synchronizes periodically (say, once in a
millisecond or less) its clock to the synchronization signal it receives
from other cards. Well, this is only dreaming ... in reality adding
jumpers, cable ports and changing chipsets costs a lot of $$$$$, so we
shouldn't expect this thing take place in (at least) cheaper soundcards
very soon.
Mikko Nummelin
This archive was generated by hypermail 2b28 : Fri Feb 27 2004 - 12:30:39 EET