[linux-audio-dev] I need help! I can't handle the problem about full-duplex (playback & record) programming
13 Dec
2002
13 Dec
'02
7:51 p.m.
Hi, guys,
I am working on a project in which I need to implement
palyback and recording on the same sound card and in
the same time.
I open the soundcard with RDWR mode and used 'select'
to wait for sound data on card and read it. After
that, I receive audio data from socket and write this
data into buffer on card. for now. I tested it and i
found if just one way, ie. just read or write, it
works fine, the quality of sound is fine. but if two
way, ie. play&record, the sound is horrible and the
weird is that I always get better sound quality from
playback that what i got from recording. (I heard the
audio from two ends). by the way, I used
SNDCTL_DSP_TRIGGER to syncronyse them.
can this method implement full-duplex functions ? if
not, what should I do? thanks in advance
leo
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
14 Dec
14 Dec
10:20 p.m.
13/12/02 15:46, leo zhu wrote:
Hi, guys,
I am working on a project in which I need to implement
palyback and recording on the same sound card and in
the same time.
I open the soundcard with RDWR mode and used 'select'
to wait for sound data on card and read it. After
that, I receive audio data from socket and write this
data into buffer on card. for now. I tested it and i
found if just one way, ie. just read or write, it
works fine, the quality of sound is fine. but if two
way, ie. play&record, the sound is horrible and the
weird is that I always get better sound quality from
playback that what i got from recording. (I heard the
audio from two ends). by the way, I used
SNDCTL_DSP_TRIGGER to syncronyse them.
can this method implement full-duplex functions ? if
not, what should I do? thanks in advance
Yes, it's possible in principle, and it can work. Although some
cards/drivers do it better than others... On Linux I believe the
easiest way is to open the audio device twice: once for reading and
once for writing. There might be other portability problems with that
method as well.
I've never gotten SNDCTL_DSP_TRIGGER to work as
expected, but that may just have been impatience.
16 Dec
16 Dec
12:19 a.m.
Hi, Haakmat,
I'm so glad to see your reply. But I'm still wondering
how I can implement the full duplex operation on sound
card, i.e. playback and record audio on the same card
at same time. I don't think it's a good idea that
reopen the device when switch between reading and
writting, because I found it sometime took much time
to open the device and that means the quality wouldn't
be good. Do u have another solution to it? Anybody
have experience with it ? I really need suggestion
about it and I also believe there must be some tricks
which I havn't understood.
Thanks a lot anyway. This is my first question in this
group and it's my pleasure to get your help.
leo.
--- Pascal Haakmat <a.haakmat(a)chello.nl> wrote:
13/12/02 15:46, leo zhu wrote:
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
Hi, guys,
I am working on a project in which I need to
implement
palyback and recording on the same sound card and
in
the same time.
I open the soundcard with RDWR mode and used
'select'
to wait for sound data on card and read it.
After
that, I receive audio data from socket and write
this
data into buffer on card. for now. I tested it
and
i
found if just one way, ie. just read or write,
it
works fine, the quality of sound is fine. but if
two
way, ie. play&record, the sound is horrible
and
the
weird is that I always get better sound quality
from
playback that what i got from recording. (I heard
the
audio from two ends). by the way, I used
SNDCTL_DSP_TRIGGER to syncronyse them.
can this method implement full-duplex functions ?
if
not, what should I do? thanks in advance
Yes, it's possible in principle, and it can work.
Although some
cards/drivers do it better than others... On Linux I
believe the
easiest way is to open the audio device twice: once
for reading and
once for writing. There might be other portability
problems with that
method as well.
I've never gotten SNDCTL_DSP_TRIGGER to work as
expected, but that may just have been impatience. 
6:35 a.m.
New subject: [linux-audio-dev] I need help! I can't handle the problem about full-duplex (playback & record) programming
On Sun, 2002-12-15 at 20:14, leo zhu wrote:
Hi, Haakmat,
I'm so glad to see your reply. But I'm still wondering
how I can implement the full duplex operation on sound
card, i.e. playback and record audio on the same card
at same time. I don't think it's a good idea that
reopen the device when switch between reading and
writting, because I found it sometime took much time
to open the device and that means the quality wouldn't
be good. Do u have another solution to it? Anybody
have experience with it ? I really need suggestion
about it and I also believe there must be some tricks
which I havn't understood.
Thanks a lot anyway. This is my first question in this
group and it's my pleasure to get your help.
leo.
You may want to look into ALSA (http://www.alsa-project.org) which is
the new Linux sound architecture. Also, it would probably be good to
make sure your audio card is actually capable of full duplex and that
this feature really does work in Linux (with the drivers you decide to
code for). I can't think of any quick and easy programs to test full
duplex (anyone else have any ideas?). Good luck.
Josh Green
8:05 a.m.
Hi,
Josh Green wrote:
[..]
You may want to look into ALSA
(http://www.alsa-project.org) which is
the new Linux sound architecture. Also, it would probably be good to
make sure your audio card is actually capable of full duplex and that
this feature really does work in Linux (with the drivers you decide to
code for). I can't think of any quick and easy programs to test full
duplex (anyone else have any ideas?). Good luck.
I think what you could do in ALSA is to make a "loopback" connection
from your soundcard's Line Out back into its Line In, then playback some
.wav or .mp3 with e.g. aplay and simultaneously (try to) use arecord(*)
to record whatever comes back in on Line In. This way it should be
possible to detect if there is some cheating going on (like, I think,
these old Soundblaster cards where "Duplex" meant 16Bit stereo playback
and at the same time 8bit stereo recording..can anyone confirm?).
(*) For those who don't know: Both aplay and arecord are part of the
alsa-utils package.
Frank
9:13 a.m.
You may want
to look into ALSA (http://www.alsa-project.org) which is
the new Linux sound architecture. Also, it would probably be good to
make sure your audio card is actually capable of full duplex and that
this feature really does work in Linux (with the drivers you decide to
code for). I can't think of any quick and easy programs to test full
duplex (anyone else have any ideas?). Good luck.
I think what you could do in ALSA is to make a "loopback" connection
from your soundcard's Line Out back into its Line In, then playback some
.wav or .mp3 with e.g. aplay and simultaneously (try to) use arecord(*)
to record whatever comes back in on Line In.
9:11 a.m.
I'm so glad to see your reply. But I'm still
wondering
how I can implement the full duplex operation on sound
card, i.e. playback and record audio on the same card
at same time. I don't think it's a good idea that
reopen the device when switch between reading and
writting, because I found it sometime took much time
to open the device and that means the quality wouldn't
be good. Do u have another solution to it? Anybody
have experience with it ? I really need suggestion
about it and I also believe there must be some tricks
which I havn't understood.
although there is a lot of experience with the OSS API here, i believe
that you will get more substantive feedback from this list by choosing
to use the ALSA API, which is the sound API in the 2.5 kernel (and
will be for 2.6 and all subsequent releases of a "stable"
kernel). most (not all!) of the developers here of full duplex
applications tend to use ALSA.
under ALSA, you open two "handles", one for read and one for
write. assuming that the card supports this in hardware (some cheap
soundblaster cards do not, for example), it works perfectly.
also, to repeat the perennial advertisement, if your application has
no reason to attach itself to a particular audio interface and might
benefit from being able to route data to/from other applications,
consider using JACK (http://jackit.sf.net/).
--p
9:33 a.m.
New subject: [linux-audio-dev] XAP and JACK
On Mon, Dec 16, 2002 at 08:09:18AM -0500, Paul Davis wrote:
also, to repeat the perennial advertisement, if your
application has
no reason to attach itself to a particular audio interface and might
benefit from being able to route data to/from other applications,
consider using JACK (http://jackit.sf.net/).
Which reminds me of some earlier thoughs: The whole discussion on XAP is
about the in process plugin model if I'm correct. Why not include an out of
process model like JACK? I suppose a union between JACK/LASDPA/XAP would be
a good thing for the linux audio community.
Of course things like callbacks are not quite handy for out of process
plugins (unless using RPC stuff). I personally like the concept of being
able to run various components in it's own process, it's own protected VM
etc. just for the sake of robustness and ease of debugging.
Frank.
--
+---- --- -- - - - -
| Frank van de Pol -o) A-L-S-A
| FvdPol(a)home.nl /\\ Sounds good!
| http://www.alsa-project.org _\_v
| Linux - Why use Windows if we have doors available?
6:36 p.m.
New subject: [linux-audio-dev] XAP and JACK
On Monday 16 December 2002 14.30, Frank van de Pol wrote:
On Mon, Dec 16, 2002 at 08:09:18AM -0500, Paul Davis
wrote:
I don't think a direct union would result in a clean API, and I don't
really see a strong motivation enough, to make up for the technical
issue and API complexity that it would imply.
* JACK is for the *really* big "plugins", that may have
their own threads for background work, direct use of
various GUI toolkits and whatnot. In short, entire
applications.
* XAP is for anything from simple effects through big,
monolith synths and samplers. A XAP plugin could be
seen as an application, but the plugin itself; the
actual DSP part that runs inside another application,
lives in a world with many restrictions. For example,
forget about using your favourite toolkit to implement
a GUI in another thread.
* LADSPA is meant to be simple. Easy to use, for both
host and plugin developers. If we make a *really*
good job with XAP and it's plugin and host SDKs, XAP
might eventually render LADSPA obsolete. My standard
comment: "You don't know anything about the future." ;-)
So, XAP is supposed to be a superset of LADSPA, and could possibly
replace it eventually. Joining the two is not an option, because it
would only result in some features being doubled.
As to JACK, there are too many technical complications to just throw
the two models into the same API.
Why use external processes and shared memory for custom XAP GUIs (or
use whatever custom toolkit we decide should go into the host SDK, if
that ever happens), when you can use JACK and whatever toolkit you
like in another thread?
Why have *both* the host oriented API of JACK, and the "stupid black
box of DSP code" philosophy of XAP in the same API, when you can
really use only one at a time? (Either you're in control of the net,
or you're not.)
also, to repeat the perennial advertisement, if
your application
has no reason to attach itself to a particular audio interface
and might benefit from being able to route data to/from other
applications, consider using JACK (http://jackit.sf.net/).
Which reminds me of some earlier thoughs: The whole discussion on
XAP is about the in process plugin model if I'm correct. Why not
include an out of process model like JACK? I suppose a union
between JACK/LASDPA/XAP would be a good thing for the linux audio
community.
Of course things like callbacks are not quite handy for out of
process plugins (unless using RPC stuff).
That would be async RPC, since you're never allowed to block the
host, unless you're a driver.
I personally like the
concept of being able to run various components in it's own
process, it's own protected VM etc. just for the sake of robustness
and ease of debugging.
Yes, that's why you should use JACK. If you do that kind of stuff,
your plugin simply cannot run as an .so plugin inside a host - part
because of the different world view, part because of conflicting
libraries; most importantly GUI toolkits.
If you just want to *develop* a legal XAP plugin in it's own process,
just use a very simple XAP host, that connects to JACK as a client.
If you want a custom GUI for your XAP plugin, well, then I'll have to
think for a few more minutes to give you a detailed answer. ;-)
Seriously, I think XAP hosts should be able to export Controls from
XAP plugins in a "soft RT" manner, to be used exactly for this
purpose. The GUIs would be registered in similar ways to plugins, and
should understand some standardized arguments, so hosts can find
them, start them up and connect them to the right instance when
desired. Obiously, the interaction would be based on the usual XAP
Events on the plugin side (no news there), while GUIs would use a
similar API. To make smooth animation and control possible, I think
GUIs should have access to timestamps and the host's current time,
but obviously, the host's event gateway would have to adjust events
that arrive late from GUIs.
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
--- http://olofson.net --- http://www.reologica.se ---
18 Dec
18 Dec
5:03 a.m.
New subject: [linux-audio-dev] XAP and JACK
On Wednesday 18 December 2002 02.51, Tim Hockin wrote:
Yeah. I'm 99.9% sure this won't conflict with the rest of the API, so
there's no need bringing this up right now. (Well, yes - it breaks
control ramping, sort of, but that's just another thing that the
host's RT/non-RT gateway has to deal with.)
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
--- http://olofson.net --- http://www.reologica.se ---
If you want a
custom GUI for your XAP plugin, well, then I'll
have to think for a few more minutes to give you a detailed
answer. ;-)
I want to discuss this, but I want to do it later :) Once the
other issues settle down.
16 Dec
16 Dec
9:57 a.m.
15/12/02 20:14, leo zhu wrote:
Hi, Haakmat,
I'm so glad to see your reply. But I'm still wondering
how I can implement the full duplex operation on sound
card, i.e. playback and record audio on the same card
at same time. I don't think it's a good idea that
reopen the device when switch between reading and
writting, because I found it sometime took much time
to open the device and that means the quality wouldn't
be good. Do u have another solution to it? Anybody
have experience with it ? I really need suggestion
about it and I also believe there must be some tricks
which I havn't understood.
I think you're confused. What I mean is that you can open /dev/dsp
twice, once for reading and once for writing, simultaneously. Then you
have one handle for reading and one handle for writing:
record_fd = open("/dev/dsp", O_RDONLY);
play_fd = open("/dev/dsp", O_WRONLY);
while(...) {
r = read(record_fd, buf, count);
store_recorded_bytes(buf, r);
fill_playback_buffer(buf, count);
write(play_fd, buf, count);
}
close(record_fd);
close(play_fd);
I.e. you don't need to close()/open() every time you switch between
reading and writing. The loop approach is crude but it works. You
might also look at ALSA which has a more sophisticated architecture.
In my experience the ALSA drivers are not as good as the (non-free)
OSS ones though.
Pascal.
7813
days inactive
7818
days old
linux-audio-dev@lists.linuxaudio.org
11 comments
8 participants
participants (8)
-
David Olofson -
Frank Neumann -
Frank van de Pol -
Josh Green -
leo zhu -
Pascal Haakmat -
Paul Davis -
Tim Hockin