If this is a network application, you may be on your way with ALSA for sound. However, for network communication and synchronization, you may want to look into Jack (the Jack Audio Connection Kit):
http://jackaudio.org/
I am sure you will get other helpful suggestions from this list.
-=Sean Edwards=-
http://jackaudio.org/
I am sure you will get other helpful suggestions from this list.
-=Sean Edwards=-
----- Original Message ----
From: John Sigler <linux.kernel@xxxxxxx>
To: alsa-user@xxxxxxxxxxxxxxxxxxxxx
Sent: Thursday, March 13, 2008 12:16:13 PM
Subject: Is ALSA the right tool for my app?
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?
--
Regards.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Alsa-user mailing list
Alsa-user@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/alsa-user
From: John Sigler <linux.kernel@xxxxxxx>
To: alsa-user@xxxxxxxxxxxxxxxxxxxxx
Sent: Thursday, March 13, 2008 12:16:13 PM
Subject: Is ALSA the right tool for my app?
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?
--
Regards.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Alsa-user mailing list
Alsa-user@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/alsa-user
Never miss a thing. Make Yahoo your homepage.
------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________ Alsa-user mailing list Alsa-user@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/alsa-user
