Re: [Alsa-user] Is ALSA the right tool for my app?

[Sergei S. <ste...@li...>]

On Thu, 13 Mar 2008 18:16:13 +0100
John Sigler <lin...@fr...> wrote:

> Hello,
> 
> I've been struggling with alsa-lib for about a week, mainly trying to 
> come up with the appropriate configuration file.
> 
> I'd like to describe what I'm trying to do, so that ALSA users might 
> tell me whether the ALSA infrastructure is the correct tool for the 
> app I'm writing.
> 
> Consider two systems A and B in separate physical locations, both 
> connected to some kind of network.
> 
> A is considered the "sender" because it captures audio, and sends it 
> to B, while B is considered the "receiver" because it receives the 
> data sent by A, and plays it back.
> 
> The code running on A is conceptually simple:
> 
> while ( 1 )
> {
>    capture a packet's worth of data (e.g. 1024 bytes)
>    add some information in a header
>    send the datagram to B
> }
> 
> The input is an AES signal. I've been told that it is very rare for 
> capture boards to provide the raw AES frames. Is this correct? If it 
> is true, the board would capture the AES payload (either PCM or 
> compressed Dolby E).
> 
> Now, to add some complexity, I'm considering a board with multiple 
> inputs, to be able to run many processes in parallel.
> 
> (I have an RME AES-32 board which provides 8 AES inputs.)
> 
> On B, the code is more complex, because the issue of synchronization 
> rears its ugly head.
> 
> B is trying to playback the stream sent by A, with a small time shift 
> (e.g. 200 ms) at the exact same rate that it was captured by A. This 
> means the code needs to buffer a number of audio frames, then start 
> the playback, and monitor the level of the hardware buffer to 
> determine whether that buffer is slowly emptying or filling up. Every 
> time B receives data from A, it pushes the data to the board's 
> hardware buffer. To keep the level constant, it might need to add or 
> remove a few frames once in a while.
> 
> The AES-32 board also provides 8 AES outputs, so I'd use another such 
> board on B. There might be several streams played back at the same time.
> 
> What is your opinion / thoughts on this architecture?
> 

Have you thought of using bigger pieces like jackd/jack-diplomat,
named pipes + netcat ?

Regards,
  Sergei.