1 Nov
2006
1 Nov
'06
3:30 a.m.
Hi everyone.
for a project, we need to be able to play sound (at first look wav file), and
we made several tests ; with a created stereo sound, we try to use alsa but
the results doesn't fullfill our needs :
sound played at the time, T, we want, and finished at the date, D=T+sound
duration.
(thi is a software with strict time constraints)
The sound was always troncated (even with finished software such as xmms,
amarok), and even randomly truncated, (sound created with audacity, and
exported as WAV 16/32 bit etc).
When we use OSS, all seems to be perfect.
But, it seems that OSS is nowadays "deprecated", and consequently we
shouldn't
use OSS. What we can do ? Are our alsa results due to misconfigurations ?
1 Nov
1 Nov
8:11 a.m.
On Wed, 01 Nov 2006 08:30:17 +0100
lemmel <lem0mel(a)gmail.com> wrote:
Hi everyone.
for a project, we need to be able to play sound (at first look wav
file), and we made several tests ; with a created stereo sound, we
try to use alsa but the results doesn't fullfill our needs :
sound played at the time, T, we want, and finished at the date, D=T
+sound duration.
(thi is a software with strict time constraints)
The sound was always troncated (even with finished software such as
xmms, amarok), and even randomly truncated, (sound created with
audacity, and exported as WAV 16/32 bit etc).
When we use OSS, all seems to be perfect.
But, it seems that OSS is nowadays "deprecated", and consequently we
shouldn't use OSS. What we can do ? Are our alsa results due to
misconfigurations ?
I am not sure I understand your problems or your needs, but my advice is
to use jack. It provides you with a very simple API that gives you
sample accurate synchronicity and hides all the hard parts like
directly dealing with the soundcard driver.
If your client code is clean enough, then you can even evaluate with
precision the latency of the software set made of your client, the
jackd server and the soundcard driver backend. If you need to know the
latency of your hardware, I invite you to google for jdelay, an
measurement app. released by M. Fons Adriensen.
Go read http://www.jackaudio.org/, you'll be delighted.
BTW, thanks a lot to all the developpers of jack !
--
David
5:20 p.m.
Le mercredi 01 novembre 2006 13:10, David a écrit :
I am not sure I understand your problems or your
needs, but my advice is
to use jack. It provides you with a very simple API that gives you
sample accurate synchronicity and hides all the hard parts like
directly dealing with the soundcard driver.
Are you sur I need to embarrase myself with an audio server, when all I need
it is to play simple wav files on a dedicated machine ?
If your client code is clean enough, then you can even
evaluate with
precision the latency of the software set made of your client, the
jackd server and the soundcard driver backend. If you need to know the
latency of your hardware, I invite you to google for jdelay, an
measurement app. released by M. Fons Adriensen.
That is quite interresting, thanks
for the information.
4:55 p.m.
lemmel wrote:
Hi everyone.
for a project, we need to be able to play sound (at first look wav file), and
we made several tests ; with a created stereo sound, we try to use alsa but
the results doesn't fullfill our needs :
sound played at the time, T, we want, and finished at the date, D=T+sound
duration.
(thi is a software with strict time constraints)
The sound was always troncated (even with finished software such as xmms,
amarok), and even randomly truncated, (sound created with audacity, and
exported as WAV 16/32 bit etc).
When we use OSS, all seems to be perfect.
But, it seems that OSS is nowadays "deprecated", and consequently we
shouldn't
use OSS. What we can do ? Are our alsa results due to misconfigurations ?
Lemmel,
This might be a bug in ALSA. open a bug on the alsa bugtracker and see
if it gets fixed.
http://alsa-project.org/
If you can include a simple test program so that developers can
reproduce the problem, that would help.
James
5:17 p.m.
Le mercredi 01 novembre 2006 21:55, vous avez écrit :
This might be a bug in ALSA. open a bug on the alsa
bugtracker and see
if it gets fixed.
http://alsa-project.org/
If you can include a simple test program so that developers can
reproduce the problem, that would help.
I don't think it is a bug :-). It is
too basic for a bug [1] :
I just made a wav file and played it with xmms and amarok (thus I can
reproduce the error by using the file). And when this players use ALSA, the
playing is bad (randomly troncated), and when the players use OSS all work
fine.
I think it is bad ALSA settings (I am just too noob to know why, perhaps
something in regard to sampling rate ?).
[1] a so plain simple bug could had been detected sooner
2 Nov
2 Nov
4:44 a.m.
lemmel wrote:
The sound was always troncated (even with finished
software such as xmms,
amarok),
Were there samples missing at the beginning or at the end?
and even randomly truncated,
What do you mean with "randomly"?
What sound card/kernel version/ALSA version are you using?
Regards,
Clemens
1:57 p.m.
Le jeudi 02 novembre 2006 09:44, vous avez écrit :
In order to
lighten, I will take an example : a 3 secondes sound file.
0------------------------------>1.5---------------------------------------->3s
a beep on a channel a beep on the other channel
the sound can be truncated at this time position : 1.5, 2, even at 1.
It is rather difficult to be accurate for the real duration is small (the wav
file is available at http://maleelma.free.fr/lemmel/test.wav.bz2), and I am
focusing on the
choice of a sound system.
Were there samples missing at the beginning or at the
end?
At the end
and even
randomly truncated,
What do you mean with "randomly"? What sound card/kernel version/ALSA version are you
using?
see an another post of mine.
4:56 p.m.
lemmel wrote:
Le jeudi 02 novembre 2006 09:44, vous avez écrit :
In order to
lighten, I will take an example : a 3 secondes sound file.
0------------------------------>1.5---------------------------------------->3s
a beep on a channel a beep on the other channel
the sound can be truncated at this time position : 1.5, 2, even at 1.
It is rather difficult to be accurate for the real duration is small (the wav
file is available at http://maleelma.free.fr/lemmel/test.wav.bz2), and I am
focusing on the
choice of a sound system.
We, unless this is actually reported to the alsa bug tracker at
http://alsa-project.org/ it might not get fixed or even investigated
further.
Were there samples missing at the beginning or at
the end?
At the end
and even
randomly truncated,
What do you mean with "randomly"? What sound card/kernel version/ALSA version are
you using?
see an another post of mine.
5:04 p.m.
James Courtier-Dutton wrote:
lemmel wrote:
This is probably an application problem. There is a special case that if
the application does not write a full period to the sound card before
calling snd_pcm_drain(), the last samples(incomplete period) written
might not be played.
The recommended way to use the sound card drivers is to use a callback
method. The callback will ask for a period at a time, so it is made
clear to the application writer that they HAVE to send an entire period.
This might help you.
James
James
Le jeudi 02 novembre 2006 09:44, vous avez écrit
:
In order to
lighten, I will take an example : a 3 secondes sound file.
0------------------------------>1.5---------------------------------------->3s
a beep on a channel a beep on the other channel
the sound can be truncated at this time position : 1.5, 2, even at 1.
It is rather difficult to be accurate for the real duration is small
(the wav file is available at
http://maleelma.free.fr/lemmel/test.wav.bz2), and I am focusing on the
choice of a sound system.
We, unless this is actually reported to the alsa bug tracker at
http://alsa-project.org/ it might not get fixed or even investigated
further.
Were there samples missing at the beginning or at
the end?
At the end
and even
randomly truncated,
What do you mean with "randomly"? What sound card/kernel version/ALSA version are
you using?
see an another post of mine.
5:50 p.m.
Le jeudi 02 novembre 2006 22:04, vous avez écrit :
This is probably an application problem. There is a
special case that if
the application does not write a full period to the sound card before
calling snd_pcm_drain(), the last samples(incomplete period) written
might not be played.
I share your point of view for I tested with aplay (see
another post), and all
works fine :-)
The recommended way to use the sound card drivers is
to use a callback
method. The callback will ask for a period at a time, so it is made
clear to the application writer that they HAVE to send an entire period.
Can you be
more precise about the function? (I a noob with sound and alsa, but
I know well dhat is a callbcak function :-) )
2:39 p.m.
Le jeudi 02 novembre 2006 09:44, vous avez écrit :
In order to
lighten, I will take an example : a 3 secondes sound file.
0------------------------------>1.5---------------------------------------->3s
a beep on a channel a beep on the other channel
the sound can be truncated at this time position : 1.5, 2, even at 1.
It is rather difficult to be accurate for the real duration is small (see an
another post of mine with the wav file enclosed), and I am focusing on the
choice of a sound system.
Were there samples missing at the beginning or at the
end?
At the end
and even
randomly truncated,
What do you mean with "randomly"? What sound card/kernel version/ALSA version are you
using?
see an another post of mine.
3:58 p.m.
On Thu, 2006-11-02 at 10:33 +0100, lemmel wrote:
Lots of people have been wondering, but this is the meat I think:
> > and even randomly truncated,
The difference in behaviour /might/ arise from differences in philosophy
of closing the device at end of file. Should we shut up now! Or wait
untill the buffer is empty ... The buffer could be incredibly huge, not
least because Linux-audio traditionally do not have RT capabilities, so
waiting for that has the potential to be very annoying. OTOH, our man is
not getting his signal through (which is also annoying )
Fast and dirty solution: Append some silence at the end of your
test-signal, enough to lure your application not to close the device
while there is still valid signal in the buffer.
Real solution: Ehh ... I get lost in ALSA documentation for users (sound
programmers that is, not device driver programmers.) Where is the
canonical "Hello World" example?
--
4:13 p.m.
On Thu, 2006-11-02 at 20:58 +0100, Jens M Andreasen wrote:
On Thu, 2006-11-02 at 10:33 +0100, lemmel wrote:
Lots of people have been wondering, but this is the meat I think:
very good point, the relevant call here is "snd_pcm_drain()". ALSA
allows you to close the device immediately (i.e. when you call
snd_pcm_close()), or when all data sent to the device has been played.
OSS doesn't provide an automatic way to select these behaviours, and I
recall from memory that you always get the second one.
which of these behaviours is correct is a very app-dependent issue.
> > and even randomly truncated,
The difference in behaviour /might/ arise from differences in philosophy
of closing the device at end of file. Should we shut up now! Or wait
untill the buffer is empty ... The buffer could be incredibly huge, not
least because Linux-audio traditionally do not have RT capabilities, so
waiting for that has the potential to be very annoying. OTOH, our man is
not getting his signal through (which is also annoying )
6591
days inactive
6592
days old
linux-audio-dev@lists.linuxaudio.org
12 comments
6 participants
participants (6)
-
Clemens Ladisch -
David -
James Courtier-Dutton -
Jens M Andreasen -
lemmel -
Paul Davis