Discussion:
alsa, oss , efficiency?
(too old to reply)
lemmel
2006-11-01 07:30:17 UTC
Permalink
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 ?
David
2006-11-01 12:10:50 UTC
Permalink
On Wed, 01 Nov 2006 08:30:17 +0100
Post by lemmel
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
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
lemmel
2006-11-01 21:20:34 UTC
Permalink
Post by David
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 ?
Post by David
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.
Kjetil S. Matheussen
2006-11-01 15:51:05 UTC
Permalink
Post by lemmel
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
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 ?
Only the oss modules in the linux kernel are deprecated. Programs using
the OSS api will still continue to work, currently most importantly
because of the oss emulation module in alsa.

If you should choose between alsa and oss, and the oss version works
just as well, or better than the alsa version, choose oss, because its a
more portable API than alsa.

However, if I were you, I would use sndlib, portaudio, jack, or some other
higher level audio input/output library instead of oss or alsa.
lemmel
2006-11-01 21:32:57 UTC
Permalink
Post by Kjetil S. Matheussen
Only the oss modules in the linux kernel are deprecated. Programs using
the OSS api will still continue to work, currently most importantly
because of the oss emulation module in alsa.
I knew that the oss module was deprecated, and I infered that using the OSS
mecanism was too deprecated :-P. Are sure [1]?
Post by Kjetil S. Matheussen
If you should choose between alsa and oss, and the oss version works
just as well, or better than the alsa version, choose oss, because its a
more portable API than alsa.
What do you mean by "the oss version works just as well, or better than the
alsa version" ?
Post by Kjetil S. Matheussen
However, if I were you, I would use sndlib, portaudio, jack, or some other
higher level audio input/output library instead of oss or alsa.
Well, all the files, that I will play, will have the same charactistics, do I
really need to bother with an hi-level API [2] ?

[1] I noticed that a lot of applications still use OSS, and I thought it was
because the migration to ALSA was too complex.
[2] Futhermore I am afraid that an hi-level API will produce time drifts in
the playing.
Paul Davis
2006-11-01 22:20:48 UTC
Permalink
Post by lemmel
Well, all the files, that I will play, will have the same charactistics, do I
really need to bother with an hi-level API [2] ?
[1] I noticed that a lot of applications still use OSS, and I thought it was
because the migration to ALSA was too complex.
[2] Futhermore I am afraid that an hi-level API will produce time drifts in
the playing.
you really have not provided us with much information on the nature of
the problem you are seeing. dozens, hundreds, perhaps even thousands of
us use ALSA and layers of software built on top of ALSA every day to
play gigabytes of audio, and have not noticed the error you describe.
perhaps you should be a lot more specific about the s/w you are using
and the error you think you are encountering.

as for time drifts when using JACK, forget about it. JACK-based software
is essentially locked into the hardware.
lemmel
2006-11-02 17:52:42 UTC
Permalink
Post by Paul Davis
you really have not provided us with much information on the nature of
the problem you are seeing.
Well my question was mainly about what sound system I should use.
Post by Paul Davis
dozens, hundreds, perhaps even thousands of
us use ALSA and layers of software built on top of ALSA every day to
play gigabytes of audio, and have not noticed the error you describe.
English is not my native tongue, I am sorry if I gived the feeling to critized
ALSA.
Post by Paul Davis
perhaps you should be a lot more specific about the s/w you are using
and the error you think you are encountering.
Well, in order to settle the matter, the wav file is available at
http://maleelma.free.fr/lemmel/test.wav.bz2,
and this is my software and hardware configuration :
- amarok 1.4.1-3
- xmms 1.2.10+20060901-2
- alsa 1.0.12-1
- linux kernel 2.6.17.8
- lspci : ALi Corporation High Definition Audio/AC'97 Host Controller (rev
01) [a 939SLI-eSATA2 motherboard, with Realtek ALC 660 5.1 channel CODEC with
HD Audio]
- no asoundrc file

the wav file contains BIP sound, first on one channel, then the other one.
File created with audacity.
Post by Paul Davis
as for time drifts when using JACK, forget about it. JACK-based software
is essentially locked into the hardware.
Well I work with a Magnetic Resonance Imaging machine (MRI), and the generated
sound must be rather accurate : the software is allowed to have a time
drifting of 1 milli-seconde in sound generation.
I was considerating that small wav files (about 3secondes) pre-loaded, will be
a good choice, what do you think ?
David
2006-11-02 20:06:18 UTC
Permalink
On Thu, 02 Nov 2006 18:52:42 +0100
Post by lemmel
Post by Paul Davis
perhaps you should be a lot more specific about the s/w you are
using and the error you think you are encountering.
Well, in order to settle the matter, the wav file is available at
http://maleelma.free.fr/lemmel/test.wav.bz2,
- amarok 1.4.1-3
- xmms 1.2.10+20060901-2
- alsa 1.0.12-1
- linux kernel 2.6.17.8
- lspci : ALi Corporation High Definition Audio/AC'97 Host
Controller (rev
01) [a 939SLI-eSATA2 motherboard, with Realtek ALC 660 5.1 channel
CODEC with HD Audio]
- no asoundrc file
the wav file contains BIP sound, first on one channel, then the other
one. File created with audacity.
Have you tried playing your file with the simple aplay command ?

$ aplay test.wav

It works fine here.
Post by lemmel
Post by Paul Davis
as for time drifts when using JACK, forget about it. JACK-based
software is essentially locked into the hardware.
Well I work with a Magnetic Resonance Imaging machine (MRI), and the
generated sound must be rather accurate : the software is allowed to
have a time drifting of 1 milli-seconde in sound generation.
I was considerating that small wav files (about 3secondes)
pre-loaded, will be a good choice, what do you think ?
If you can do without the on-the-fly generation of the sound clips, it
might be easier to have them preloaded, yes.

HTH
--
David
lemmel
2006-11-02 21:26:04 UTC
Permalink
Post by David
Have you tried playing your file with the simple aplay command ?
$ aplay test.wav
It works fine here.
It is the same for me, it works fine with aplay, but not with xmms and
amarok ??!!!
Post by David
If you can do without the on-the-fly generation of the sound clips, it
might be easier to have them preloaded, yes.
What is "generation of the sound clips" ?
David
2006-11-03 00:08:57 UTC
Permalink
On Thu, 02 Nov 2006 22:26:04 +0100
Post by lemmel
Post by David
Have you tried playing your file with the simple aplay command ?
$ aplay test.wav
It works fine here.
It is the same for me, it works fine with aplay, but not with xmms
and amarok ??!!!
As wise people already told you, different apps with different goals
behave differently ...

The test with aplay at least shows that your ALSA setup is ok and that
the flammable debate about ALSA vs OSS is not the point in your case.

If you want help here, you really should try to give a clearer
explanation of what you are trying to achieve. You are talking with
highly knowledgeable persons on this list, myself belonging to the
least knowledgeable ones, I am ordinarily part of the "silent lurkers".

What I could gather from this thread goes from "I can't play this wav
file" to "I need to link synchronous audio to magnetic resonance
imaging" (quotes are mine). Please try to clearly state your case or
you won't be answered in any helpful way.
Post by lemmel
Post by David
If you can do without the on-the-fly generation of the sound clips,
it might be easier to have them preloaded, yes.
What is "generation of the sound clips" ?
I was just supposing you could need to generate sound data from
realtime events/data. If your need is to "play" predefined sound data
when needed, then you're better off with keeping it in memory, as long
as its size remains compatible with your hardware.

HTH
--
David
Hannu Savolainen
2006-11-02 14:51:19 UTC
Permalink
Hi folks,

The "deprecated" OSS issue needs some clarification. It's just the
OSS/Free drivers that are still hanging around in the kernel. that are
depracated. They are based on 10 years old version of the OSS
architecture and lack all the improvements and features added during
past years.

However the real OSS by 4Front Technoliges is there to stay. While OSS
is "binary only" at this moment the situation is changing. We are about
to release OSS 4.0 under some open source license. We still need to
decide the exact license (GPL, CDDL, BSD or some combination of them)
before releasing the sources but that should happen in the near future
(maybe weeks or months).

The whole "OSS is depracated" issue is just marketing propaganda used
to enforce application developers to jump to the ALSA API. Without this
developers would stick with OSS which is several magnitudes easier API
to use.

OSS and ALSA are very different APIs. OSS is designed for professional
software developers who should get their job done within tight
schedules. For this reason it has strong device abstraction. Everything
that could be automated has been automated. ALSA in turn is designed for
hackers (in the 1st place) who like to tweak every possible detail of
the hardware. This means there is practically no device abstraction and
the application should be more or less aware of the capabilities of the
hardware. Which API works better depends on the nature of the
application. This decision should not be driven by some political issues
as today.

My message is that if you prefer OSS over ALSA then there is no need to
convert the code. OSS has been in the shadows during past couple of
years. However it will be back, We are working on an OSS version that
makes it possible to ALSA and OSS to co-exist. Both OSS and ALSA will be
_native_ code (no emulation). In this way all Linux audio applications
will work regardless of which API they use.

Best regards,

Hannu
Post by lemmel
Post by Kjetil S. Matheussen
Only the oss modules in the linux kernel are deprecated. Programs using
the OSS api will still continue to work, currently most importantly
because of the oss emulation module in alsa.
I knew that the oss module was deprecated, and I infered that using the OSS
mecanism was too deprecated :-P. Are sure [1]?
Post by Kjetil S. Matheussen
If you should choose between alsa and oss, and the oss version works
just as well, or better than the alsa version, choose oss, because its a
more portable API than alsa.
What do you mean by "the oss version works just as well, or better than the
alsa version" ?
Post by Kjetil S. Matheussen
However, if I were you, I would use sndlib, portaudio, jack, or some other
higher level audio input/output library instead of oss or alsa.
Well, all the files, that I will play, will have the same charactistics, do I
really need to bother with an hi-level API [2] ?
[1] I noticed that a lot of applications still use OSS, and I thought it was
because the migration to ALSA was too complex.
[2] Futhermore I am afraid that an hi-level API will produce time drifts in
the playing.
lemmel
2006-11-02 19:44:12 UTC
Permalink
Post by Hannu Savolainen
Hi folks,
Hi and thanks for the mail :-)
Post by Hannu Savolainen
[...]
However the real OSS by 4Front Technoliges is there to stay. While OSS
is "binary only" at this moment the situation is changing. We are about
to release OSS 4.0 under some open source license. We still need to
decide the exact license (GPL, CDDL, BSD or some combination of them)
before releasing the sources but that should happen in the near future
(maybe weeks or months).
I found your website when I looked for information, and it is true :-) that
the "OSS deprecated" blurred my valuation. You say that you will make a
release with an Opensource licence, but when ?
Post by Hannu Savolainen
Without this
developers would stick with OSS which is several magnitudes easier API
to use.
Can you justify your point ?
Post by Hannu Savolainen
OSS and ALSA are very different APIs. OSS is designed for professional
software developers who should get their job done within tight
schedules. For this reason it has strong device abstraction. Everything
that could be automated has been automated. ALSA in turn is designed for
hackers (in the 1st place) who like to tweak every possible detail of
the hardware. This means there is practically no device abstraction and
the application should be more or less aware of the capabilities of the
hardware. Which API works better depends on the nature of the
application. This decision should not be driven by some political issues
as today.
And for my problem, what do you suggest ? (look at an another posted mail )
Josef Jurek
2006-11-02 20:01:58 UTC
Permalink
Hannu Savolainen <***@opensound.com> writes:
[...]
Post by Hannu Savolainen
The whole "OSS is depracated" issue is just marketing propaganda used
to enforce application developers to jump to the ALSA API. Without this
developers would stick with OSS which is several magnitudes easier API
to use.
"Marketing propaganda?" 4Front Technologies is a company that
engages in the sale of software for profit. 4Front Technologies therefore
requires and presumably has a "market", people who pay them for their
products. I don't think the same situation exists for those
who develop ALSA.
Post by Hannu Savolainen
OSS and ALSA are very different APIs. OSS is designed for professional
software developers who should get their job done within tight
schedules. For this reason it has strong device abstraction. Everything
that could be automated has been automated. ALSA in turn is designed for
hackers (in the 1st place) who like to tweak every possible detail of
the hardware. This means there is practically no device abstraction and
the application should be more or less aware of the capabilities of the
hardware. Which API works better depends on the nature of the
application. This decision should not be driven by some political issues
as today.
So you say:

OSS: professional software developers
ALSO: hackers

How do others feel about this issue. Here is an example
from past discussion:

From: Paul Davis <***@Op.Net>
Date: Tue, 03 Apr 2001 16:15:53 -0400
To: LAD <linux-audio-***@ginette.musique.umontreal.ca>
Subject: Re: [linux-audio-dev] efficient non-blocking writes to /dev/dsp
Post by Hannu Savolainen
I would like to know what's wrong with OSS API?
its impossible to use it in an efficient hardware-independent fashion,
because it has no concept of noninterleaved data streams. every time
you want to add a new concept to it, such as changing the sample clock
sync source, it can only be done via a new ioctl, which is rarely done
in a h/w independent fashion but instead as a card-specific hack. the
direct use of system calls means that its impossible to do the "grunt"
work of, say, resampling or sample bitwidth changes in user space -
this is all forced into the kernel. the system call-based API also
prevents the interposition of additional layers to provide
abstraction: the alsa-oss library, which is coming along very nicely
as a way to get *full* ALSA functionality even when using /dev/dsp
(rather than just OSS functionality via "emulation"), can only work by
using the LD_PRELOAD hack. there's no way to "bind" physical
connectors to channels in the OSS model: every OSS-based multichannel
driver so far has allowed wierd things like "well, this time when i
asked for 10 channels, I got channels 1-10, but the last time, it was
2-12". the kernel code has no interesting "midlevel" layer, forcing
many drivers to either offer limited functionality or duplicate code
from other drivers. need i go on ?

basically, the OSS API is based on h/w models from the SB16 era; ALSA
has successfully incorporated lots of lessons from devices like the
Hammerfall, the ice1712-based devices and others.

--p


[...]
Post by Hannu Savolainen
My message is that if you prefer OSS over ALSA then there is no need to
convert the code. OSS has been in the shadows during past couple of
years. However it will be back, We are working on an OSS version that
makes it possible to ALSA and OSS to co-exist.
Probably, the widespread adoption of ALSA by the linux community
gave you no choice but to develop such a version of OSS, no?

Oh, and you mis-spelled "4Front Technologies"
Loki Davison
2006-11-03 02:42:25 UTC
Permalink
Post by Josef Jurek
[...]
Post by Hannu Savolainen
The whole "OSS is depracated" issue is just marketing propaganda used
to enforce application developers to jump to the ALSA API. Without this
developers would stick with OSS which is several magnitudes easier API
to use.
"Marketing propaganda?" 4Front Technologies is a company that
engages in the sale of software for profit. 4Front Technologies therefore
requires and presumably has a "market", people who pay them for their
products. I don't think the same situation exists for those
who develop ALSA.
Post by Hannu Savolainen
OSS and ALSA are very different APIs. OSS is designed for professional
software developers who should get their job done within tight
schedules. For this reason it has strong device abstraction. Everything
that could be automated has been automated. ALSA in turn is designed for
hackers (in the 1st place) who like to tweak every possible detail of
the hardware. This means there is practically no device abstraction and
the application should be more or less aware of the capabilities of the
hardware. Which API works better depends on the nature of the
application. This decision should not be driven by some political issues
as today.
OSS: professional software developers
ALSA: hackers
mmm. I think they are missing the point about ALSA vs OSS api here. It
doesn't matter. The only one who should care about alsa vs oss is the
jack guys who write the jack backend. Everyone else uses the clear,
nice, well implemented, well documented modern and sensible jack api
instead of some very 80's style pipe based system.

Have you tried OSS for midi? ARRG horrible flashbacks. Any app using
oss for midi is automatically classed as useless by me. Good bye
timing, good by flexibility hello dodgyness!

Portability wise how is OSS better than jack? Jack runs on posix
systems (mac, linux, etc) and there seems to be action on the windoze
front. OSS for portability is silly, everyone gets screwed over in the
features department for really no uses to get anything out of it. How
do you record the output of an OSS app nicely? Route it to
timemachine... i don't think so. Look at the example jack apps. So
easy!

Loki
Jens M Andreasen
2006-11-03 07:29:50 UTC
Permalink
Post by Loki Davison
mmm. I think they are missing the point about ALSA vs OSS api here. It
doesn't matter. The only one who should care about alsa vs oss is the
jack guys who write the jack backend. Everyone else uses the clear,
nice, well implemented, well documented modern and sensible jack api
instead of some very 80's style pipe based system.
JACK isn't based on "some very 80' style" named pipes anymore? When did
that happen?
Loki Davison
2006-11-03 07:37:13 UTC
Permalink
Post by Jens M Andreasen
Post by Loki Davison
mmm. I think they are missing the point about ALSA vs OSS api here. It
doesn't matter. The only one who should care about alsa vs oss is the
jack guys who write the jack backend. Everyone else uses the clear,
nice, well implemented, well documented modern and sensible jack api
instead of some very 80's style pipe based system.
JACK isn't based on "some very 80' style" named pipes anymore? When did
that happen?
I actually meant vs a callback based system. Jack being callback based
makes it easier to understand in my mind. I didn't mention named
pipes, just the | <> signs. Even without the pipe section i think the
comment still stands. As a person new to all 3 i found jack by far the
easiest to understand and use.

Loki
Fons Adriaensen
2006-11-03 07:53:30 UTC
Permalink
Post by Loki Davison
Post by Jens M Andreasen
Post by Loki Davison
mmm. I think they are missing the point about ALSA vs OSS api here. It
doesn't matter. The only one who should care about alsa vs oss is the
jack guys who write the jack backend. Everyone else uses the clear,
nice, well implemented, well documented modern and sensible jack api
instead of some very 80's style pipe based system.
JACK isn't based on "some very 80' style" named pipes anymore? When did
that happen?
I actually meant vs a callback based system. Jack being callback based
makes it easier to understand in my mind. I didn't mention named
pipes, just the | <> signs. Even without the pipe section i think the
comment still stands. As a person new to all 3 i found jack by far the
easiest to understand and use.
I'd say that the essential feature of JACK is not that it is a
callback based system, but that it presents and expects audio
data in fixed size blocks and enforces the rule that all clients
must have processed a block before the next arrives.

This could be done with blocking as well as with a callback,
and indeed it would be useful if JACK offered that option.
--
FA

Lascia la spina, cogli la rosa.
Simon Jenkins
2006-11-03 16:39:18 UTC
Permalink
Post by Fons Adriaensen
[...]
I'd say that the essential feature of JACK is not that it is a
callback based system, but that it presents and expects audio
data in fixed size blocks and enforces the rule that all clients
must have processed a block before the next arrives.
This could be done with blocking as well as with a callback,
and indeed it would be useful if JACK offered that option.
Fons, I remember your mail to jackit-devel on this subject:

http://sourceforge.net/mailarchive/message.php?msg_id=14073424

I had a question at the time which I didn't get around to asking which
is... What about event processing? (ie GraphReordered, BufferSizeChange
etc) These are delivered to the same thread in libjack that waits on the
buffers so they would be turning up somewhere inside your proposed
jack_thread_wait() function.

Two possible approaches would be:

a) Stick with callbacks for events
b) Poll for events

In either case when you called jack_thread_wait() it would wait for
events and/or a buffer. The difference is that in a) it would call a
callback whenever it got an event but only return to caller when it got
a buffer, whereas in b) it would return to caller on either an event or
a buffer with an indication of which had arrived.

a) would be easiest and I can't see any advantage in b). What do you
think?

Simon
Stéphane Letz
2006-11-03 16:50:02 UTC
Permalink
Post by Simon Jenkins
Post by Fons Adriaensen
[...]
I'd say that the essential feature of JACK is not that it is a
callback based system, but that it presents and expects audio
data in fixed size blocks and enforces the rule that all clients
must have processed a block before the next arrives.
This could be done with blocking as well as with a callback,
and indeed it would be useful if JACK offered that option.
http://sourceforge.net/mailarchive/message.php?msg_id=14073424
I had a question at the time which I didn't get around to asking which
is... What about event processing? (ie GraphReordered,
BufferSizeChange
etc) These are delivered to the same thread in libjack that waits on the
buffers so they would be turning up somewhere inside your proposed
jack_thread_wait() function.
a) Stick with callbacks for events
b) Poll for events
In either case when you called jack_thread_wait() it would wait for
events and/or a buffer. The difference is that in a) it would call a
callback whenever it got an event but only return to caller when it got
a buffer, whereas in b) it would return to caller on either an
event or
a buffer with an indication of which had arrived.
a) would be easiest and I can't see any advantage in b). What do you
think?
Simon
c) or move to a 2 threads model: one for RT audio, one for
notification event handling

Stephane
Simon Jenkins
2006-11-03 17:16:40 UTC
Permalink
Post by Stéphane Letz
Post by Simon Jenkins
Post by Fons Adriaensen
[...]
I'd say that the essential feature of JACK is not that it is a
callback based system, but that it presents and expects audio
data in fixed size blocks and enforces the rule that all clients
must have processed a block before the next arrives.
This could be done with blocking as well as with a callback,
and indeed it would be useful if JACK offered that option.
http://sourceforge.net/mailarchive/message.php?msg_id=14073424
I had a question at the time which I didn't get around to asking which
is... What about event processing? (ie GraphReordered,
BufferSizeChange
etc) These are delivered to the same thread in libjack that waits on the
buffers so they would be turning up somewhere inside your proposed
jack_thread_wait() function.
a) Stick with callbacks for events
b) Poll for events
In either case when you called jack_thread_wait() it would wait for
events and/or a buffer. The difference is that in a) it would call a
callback whenever it got an event but only return to caller when it got
a buffer, whereas in b) it would return to caller on either an event or
a buffer with an indication of which had arrived.
a) would be easiest and I can't see any advantage in b). What do you
think?
Simon
c) or move to a 2 threads model: one for RT audio, one for
notification event handling
Possible, but a lot more effort in current JACK and no good reason (that
I can see at the moment) to do it that way.

How about jackdmp? Which of a) b) or c) would be easier or better there?

Simon
Post by Stéphane Letz
Stephane
Stéphane Letz
2006-11-03 17:19:09 UTC
Permalink
Post by Simon Jenkins
Post by Stéphane Letz
Post by Simon Jenkins
Post by Fons Adriaensen
[...]
I'd say that the essential feature of JACK is not that it is a
callback based system, but that it presents and expects audio
data in fixed size blocks and enforces the rule that all clients
must have processed a block before the next arrives.
This could be done with blocking as well as with a callback,
and indeed it would be useful if JACK offered that option.
http://sourceforge.net/mailarchive/message.php?msg_id=14073424
I had a question at the time which I didn't get around to asking which
is... What about event processing? (ie GraphReordered,
BufferSizeChange
etc) These are delivered to the same thread in libjack that waits on the
buffers so they would be turning up somewhere inside your proposed
jack_thread_wait() function.
a) Stick with callbacks for events
b) Poll for events
In either case when you called jack_thread_wait() it would wait for
events and/or a buffer. The difference is that in a) it would call a
callback whenever it got an event but only return to caller when it got
a buffer, whereas in b) it would return to caller on either an event or
a buffer with an indication of which had arrived.
a) would be easiest and I can't see any advantage in b). What do you
think?
Simon
c) or move to a 2 threads model: one for RT audio, one for
notification event handling
Possible, but a lot more effort in current JACK and no good reason (that
I can see at the moment) to do it that way.
How about jackdmp? Which of a) b) or c) would be easier or better there?
Simon
jackdmp is c) already.

Stephane
Post by Simon Jenkins
Post by Stéphane Letz
Stephane
Fons Adriaensen
2006-11-03 17:10:57 UTC
Permalink
Post by Simon Jenkins
Post by Fons Adriaensen
[...]
I'd say that the essential feature of JACK is not that it is a
callback based system, but that it presents and expects audio
data in fixed size blocks and enforces the rule that all clients
must have processed a block before the next arrives.
This could be done with blocking as well as with a callback,
and indeed it would be useful if JACK offered that option.
http://sourceforge.net/mailarchive/message.php?msg_id=14073424
I had a question at the time which I didn't get around to asking which
is... What about event processing? (ie GraphReordered, BufferSizeChange
etc) These are delivered to the same thread in libjack that waits on the
buffers so they would be turning up somewhere inside your proposed
jack_thread_wait() function.
There is no problem with this. They are handled in libjack which
will call one of the user's callbacks. This happens in the code block
named 'A' in my proposal, just as it does now.

The fact that we are inside jack_thread_wait() doesn't matter at all
- the callback is a function call like any other. The two forms are
really equivalent !

The event could arrive at an inconvenient time for the client,
but that is also the case in the normal structure. The worst
that could happen is that an algorithm has to be terminated
while it is still threaded. If that's the case you have to
code for it.
--
FA

Lascia la spina, cogli la rosa.
Jens M Andreasen
2006-11-03 17:55:06 UTC
Permalink
Post by Loki Davison
I actually meant vs a callback based system. Jack being callback based
makes it easier to understand in my mind. I didn't mention named
pipes, just the | <> signs. Even without the pipe section i think the
comment still stands. As a person new to all 3 i found jack by far the
easiest to understand and use.
You have used shell syntax as a glue between various audio applications?
Hats off to you then, I would have thought to be unpossible, that gcc
was a minimum requirement ... at least I am not getting anywhere without
taking that route, opening an audio device using 'ioctl' ( ... which I
copy/pasted from another app, not totally unlike how one would copy
'simple_jack_client' and fill in the blanks)
Post by Loki Davison
Loki
--
Loki Davison
2006-11-04 01:56:42 UTC
Permalink
Post by Jens M Andreasen
Post by Loki Davison
I actually meant vs a callback based system. Jack being callback based
makes it easier to understand in my mind. I didn't mention named
pipes, just the | <> signs. Even without the pipe section i think the
comment still stands. As a person new to all 3 i found jack by far the
easiest to understand and use.
You have used shell syntax as a glue between various audio applications?
Hats off to you then, I would have thought to be unpossible, that gcc
was a minimum requirement ... at least I am not getting anywhere without
taking that route, opening an audio device using 'ioctl' ( ... which I
copy/pasted from another app, not totally unlike how one would copy
'simple_jack_client' and fill in the blanks)
Post by Loki Davison
Loki
--
cat thing.au > /dev/dsp works on some systems. I'm not saying it makes
total sense though.

Loki
Hannu Savolainen
2006-11-06 10:46:37 UTC
Permalink
Post by Josef Jurek
"Marketing propaganda?" 4Front Technologies is a company that
engages in the sale of software for profit. 4Front Technologies therefore
requires and presumably has a "market", people who pay them for their
products.
4Front Technologies is just three programmers/developers. There is no
marketing people.
Post by Josef Jurek
I don't think the same situation exists for those
who develop ALSA.
So you didn't know that key members of the ALSA team have been employees
of SuSE.

Best regards,

Hannu
Fernando Lopez-Lezcano
2006-11-06 18:36:51 UTC
Permalink
Post by Hannu Savolainen
Post by Josef Jurek
"Marketing propaganda?" 4Front Technologies is a company that
engages in the sale of software for profit. 4Front Technologies therefore
requires and presumably has a "market", people who pay them for their
products.
4Front Technologies is just three programmers/developers. There is no
marketing people.
Ahem... In my eyes the stuff you posted _is_ marketing. Nothing wrong
with that, of course, just don't be surprised if the target audience
does not buy into it.
Post by Hannu Savolainen
Post by Josef Jurek
I don't think the same situation exists for those
who develop ALSA.
So you didn't know that key members of the ALSA team have been employees
of SuSE.
My feeling is that technical factors favored ALSA over OSS (not to say
that the ALSA api is complete or perfect, of course). Obviously you and
others disagree about that. Re: SuSE, I don't know if Jaroslav was hired
before he started work on ALSA, or after ALSA had been around for a
while, I suspect the later.

Another important factor other than the (crucial) technical stuff is
that ALSA has been completely open from the get go, one of the very
reasons I switched a long time ago.

-- Fernando
Dave Robillard
2006-11-04 03:52:04 UTC
Permalink
Post by Hannu Savolainen
Hi folks,
The "deprecated" OSS issue needs some clarification. It's just the
OSS/Free drivers that are still hanging around in the kernel. that are
depracated. They are based on 10 years old version of the OSS
architecture and lack all the improvements and features added during
past years.
However the real OSS by 4Front Technoliges is there to stay. While OSS
is "binary only" at this moment the situation is changing. We are about
to release OSS 4.0 under some open source license. We still need to
decide the exact license (GPL, CDDL, BSD or some combination of them)
before releasing the sources but that should happen in the near future
(maybe weeks or months).
The whole "OSS is depracated" issue is just marketing propaganda used
to enforce application developers to jump to the ALSA API. Without this
developers would stick with OSS which is several magnitudes easier API
to use.
Yeah, and you're clearly not biased.

If 4front wanted to stay relevant in Linux, the time to open up was
years and years ago. They open it now because Alsa killed OSS? Gee, no
kidding.

In related news, Sun opens Solaris and all Linux users immediately drop
Linux for Solaris. After all, the real Unix from Sun Microsystems is
here to stay!

Anyway, apps should not be directly using EITHER Alsa or OSS.

-DR-
Lee Revell
2006-11-06 18:39:43 UTC
Permalink
Post by Hannu Savolainen
Hi folks,
The "deprecated" OSS issue needs some clarification. It's just the
OSS/Free drivers that are still hanging around in the kernel. that are
depracated. They are based on 10 years old version of the OSS
architecture and lack all the improvements and features added during
past years.
Real linux drivers reside in the mainline kernel. Out of tree stuff is
is irrelevant.

Also, you've been promising for years that OSS will be free software
again, I doubt anyone believes you at this point.

Lee
Paul Winkler
2006-11-06 21:38:06 UTC
Permalink
Post by Lee Revell
Real linux drivers reside in the mainline kernel. Out of tree stuff is
is irrelevant.
I don't think that's a fair blanket statement given that drivers often
begin life outside the mainline kernel tree. ALSA, for example.
--
Paul Winkler
http://www.slinkp.com
Paul Davis
2006-11-06 22:11:17 UTC
Permalink
Post by Paul Winkler
Post by Lee Revell
Real linux drivers reside in the mainline kernel. Out of tree stuff is
is irrelevant.
I don't think that's a fair blanket statement given that drivers often
begin life outside the mainline kernel tree. ALSA, for example.
i also think its not necessary to be so antagonistic towards 4 Front or
OSS.

Hannu was the guy who made sound on linux possible in the first place.
Have a little respect. OK, so he and others decided to try to make a
business out of it, and they bowed down to NDA requirements from vendors
as part of doing that. Many of us never liked the results of that
decision, but its an understandable and, from some points of view, a
defensible one too.

I continue to have disagreements with the technical decisions that Hannu
and others made with OSS' design. Other people I respect (hi Guenter)
continue to prefer the OSS design. Either way, lets have a little
respect for someone who got the SB cards, the incredible Gravis
Ultrasound and many other devices working, who offered help to others
trying to write drivers and generally has had a lot of similar goals
that many LAD members do.

--p
James Courtier-Dutton
2006-11-07 00:29:42 UTC
Permalink
Post by Paul Davis
Hannu was the guy who made sound on linux possible in the first place.
Have a little respect. OK, so he and others decided to try to make a
business out of it, and they bowed down to NDA requirements from vendors
as part of doing that. Many of us never liked the results of that
decision, but its an understandable and, from some points of view, a
defensible one too.
NDAs are not all bad. I signed an NDA with creative, and the result is
better support for open source drivers for Audigy and E-MU cards. I
choose the GPL license for my code, but I could have chosen any other
license I wanted.
I am not allowed to copy the datasheets themselves, but I can write
anything I like in the source code. I.e. comments etc.
So, I don't believe the argument that signing NDAs requires closed
source drivers.

James

P.S. For those interested, there is now an ALSA driver for the E-MU
1212m and E-MU 1820m.
Pieter Palmers
2006-11-07 14:12:51 UTC
Permalink
Post by James Courtier-Dutton
Post by Paul Davis
Hannu was the guy who made sound on linux possible in the first place.
Have a little respect. OK, so he and others decided to try to make a
business out of it, and they bowed down to NDA requirements from vendors
as part of doing that. Many of us never liked the results of that
decision, but its an understandable and, from some points of view, a
defensible one too.
NDAs are not all bad. I signed an NDA with creative, and the result is
better support for open source drivers for Audigy and E-MU cards. I
choose the GPL license for my code, but I could have chosen any other
license I wanted.
I am not allowed to copy the datasheets themselves, but I can write
anything I like in the source code. I.e. comments etc.
So, I don't believe the argument that signing NDAs requires closed
source drivers.
I also signed a NDA to get the documents to work on FreeBoB. I don't see
a problem there, as long as the NDA doesn't restrict me with respect to
the licensing of FreeBoB.

Pieter
Ctirad Fertr
2006-11-07 15:39:19 UTC
Permalink
Post by James Courtier-Dutton
P.S. For those interested, there is now an ALSA driver for the E-MU
1212m and E-MU 1820m.
Excellent news! It is already usable for serious work? Is it compatible with
the current 1212M v2 revision?

Best regards,

Ctirad
Patrick Shirkey
2006-11-07 00:41:31 UTC
Permalink
Post by Paul Davis
I continue to have disagreements with the technical decisions that Hannu
and others made with OSS' design. Other people I respect (hi Guenter)
continue to prefer the OSS design. Either way, lets have a little
respect for someone who got the SB cards, the incredible Gravis
Ultrasound and many other devices working, who offered help to others
trying to write drivers and generally has had a lot of similar goals
that many LAD members do.
I think Hannu annoyed a few of us by stating that ALSA is designed by
hackers.

There is absolutely no question in my mind that ALSA is designed by
professionals. The difference is that 4Front is a company whereas ALSA
is a group of individuals, several of whom are employed to work on the
drivers or derive income thereof.

Many people have commented that 4Front have made their install and
configuration system very user friendly. That's definitely something
that the ALSA Project could improve but as the product is not being sold
it's not a priority and the docs are fairly complete. I like to think of
it as an enforced learning curve.

Installing the ALSA drivers is not the hardest task that Linux Audio
Users are confronted with anymore.
--
Patrick Shirkey - Boost Hardware Ltd.
Http://www.boosthardware.com
Http://lau.linuxaudio.org - The Linux Audio Users guide
========================================

"Anything your mind can see you can manifest physically, then it will
become reality" - Macka B
Garett Shulman
2006-11-07 14:56:52 UTC
Permalink
Post by Patrick Shirkey
I think Hannu annoyed a few of us by stating that ALSA is designed by
hackers.
There is absolutely no question in my mind that ALSA is designed by
professionals.
True. However... there are definitely some hackish aspects to the alsa
project. On numerous occasions I have found the files created by alsactl
for my ice1712's to break from version to version of ALSA. Then I have
to check what the mixer settings where, reset them manually, and run
alsactl store again. Lame. The plugin infrastructure seems to often be
variously broken... except for the sample rate & bit rate plugin... and
perhaps dmix. I was able to get dshare working pretty well once... but
an alsa upgrade broke that.

But... it's gratis & libre & generally works great under Jack. So...
Thank you ALSA Team!

If you ask me... I would recommend that the alsa team drop all of the
ambitions plugin stuff (except sampl rate & bit rate) and focus on
building the most stable & broadly supported hardware abstraction for jack.
John Rigg
2006-11-07 16:54:07 UTC
Permalink
Post by Garett Shulman
If you ask me... I would recommend that the alsa team drop all of the
ambitions plugin stuff (except sampl rate & bit rate)
Without `ambitious plugin stuff' like pcm_multi, nobody would be able
to use multiple sound cards with ALSA. The fact that pcm_multi has needed
patching since January 2005 to make it work in duplex mode with jackd
is only a minor inconvenience compared with not having it at all.

John
Lee Revell
2006-11-07 16:42:40 UTC
Permalink
Post by John Rigg
Post by Garett Shulman
If you ask me... I would recommend that the alsa team drop all of the
ambitions plugin stuff (except sampl rate & bit rate)
Without `ambitious plugin stuff' like pcm_multi, nobody would be able
to use multiple sound cards with ALSA. The fact that pcm_multi has needed
patching since January 2005 to make it work in duplex mode with jackd
is only a minor inconvenience compared with not having it at all.
Please, please keep pushing the ALSA guys to fix this. I keep raising
the issue and every time the thread peters out with no resolution.

Lee
Post by John Rigg
John
James Courtier-Dutton
2006-11-08 00:20:42 UTC
Permalink
Post by Lee Revell
Post by John Rigg
Post by Garett Shulman
If you ask me... I would recommend that the alsa team drop all of the
ambitions plugin stuff (except sampl rate & bit rate)
Without `ambitious plugin stuff' like pcm_multi, nobody would be able
to use multiple sound cards with ALSA. The fact that pcm_multi has needed
patching since January 2005 to make it work in duplex mode with jackd
is only a minor inconvenience compared with not having it at all.
Please, please keep pushing the ALSA guys to fix this. I keep raising
the issue and every time the thread peters out with no resolution.
Lee
I don't know the details, but it is probably due to jackd not using the
poll api in the way alsa recommends.
The current jackd skips a step in the processing of the poll events.

James
Fons Adriaensen
2006-11-08 13:09:23 UTC
Permalink
Post by James Courtier-Dutton
The current jackd skips a step in the processing of the poll events.
Looking at the code it seems already quite elaborate.

Basically what happens comes down to (ignoring error
checking and timeouts):

- The set of pollfd is poll()'ed until all are ready.
- Within each iteration of the loop the pollfd used
are re-initialised by a call to the alsa library.
- There is one optimisation: the pollfd are divided
into two groups, one for capture and one for playback.
A group that is complete is not polled again.

I use similar code in libclalsadrv and in a new
jackd backend that I wrote last week.

What is misssing ?
--
FA

Lascia la spina, cogli la rosa.
Clemens Ladisch
2006-11-08 13:12:09 UTC
Permalink
Post by Fons Adriaensen
Post by James Courtier-Dutton
The current jackd skips a step in the processing of the poll events.
Basically what happens comes down to (ignoring error
- The set of pollfd is poll()'ed until all are ready.
Applications must not look at ALSA's pollfds, they must use
snd_pcm_poll_descriptors_revents() instead.


Regards,
Clemens
Fons Adriaensen
2006-11-08 13:24:30 UTC
Permalink
Post by Clemens Ladisch
Post by Fons Adriaensen
Basically what happens comes down to (ignoring error
- The set of pollfd is poll()'ed until all are ready.
Applications must not look at ALSA's pollfds, they must use
snd_pcm_poll_descriptors_revents() instead.
Given that poll() is a system call and that the struct used
by it is a system type and not one of ALSA's private ones,
what is wrong with looking at it ?

Is snd_pcm_poll_descriptors_revents() more than an
accessor ? If it is, the name is a quite misleading.
--
FA

Lascia la spina, cogli la rosa.
Fons Adriaensen
2006-11-08 14:42:05 UTC
Permalink
Post by Fons Adriaensen
Is snd_pcm_poll_descriptors_revents() more than an
accessor ? If it is, the name is a quite misleading.
To answer my own question, it seems that it *is* more
than an accessor.

The docs leave one thing unclear. Does this call require
an array of unsigned short int (one per pollfd), or are
events from all pollfds combined into one revents value ?

The example code in test.pcm seems to indicate the latter.

In that case, how can one test if *all* pollfd for a given
pcm are ready ?
--
FA

Lascia la spina, cogli la rosa.
Clemens Ladisch
2006-11-08 16:58:40 UTC
Permalink
Post by Fons Adriaensen
Post by Fons Adriaensen
Is snd_pcm_poll_descriptors_revents() more than an
accessor ? If it is, the name is a quite misleading.
To answer my own question, it seems that it *is* more
than an accessor.
The docs leave one thing unclear. Does this call require
an array of unsigned short int (one per pollfd), or are
events from all pollfds combined into one revents value?
It returns one revents value for the PCM device.
Post by Fons Adriaensen
In that case, how can one test if *all* pollfd for a given
pcm are ready ?
You cannot. The state of the file descriptors is not necessarily
related to the state of the PCM device (which is why this function
exists).


Regards,
Clemens
Fons Adriaensen
2006-11-08 18:47:51 UTC
Permalink
Post by Clemens Ladisch
Post by Fons Adriaensen
In that case, how can one test if *all* pollfd for a given
pcm are ready ?
You cannot. The state of the file descriptors is not necessarily
related to the state of the PCM device (which is why this function
exists).
OK, thanks.

So a loop waiting for both capture and playback being ready
could be something like (cut down to the bare minimum):


n_play = driver->play_parm.npoll;
n_capt = driver->capt_parm.npoll;
while (n_play || n_capt)
{
if (n_play) snd_pcm_poll_descriptors (driver->play_parm.handle, pfd, n_play);
if (n_capt) snd_pcm_poll_descriptors (driver->capt_parm.handle, pfd + n_play, n_capt);
prv = poll (pfd, n_play + n_capt, 1000);
if (prv < 0)
{
if (errno == EINTR) return ERR1;
return ERR2;
}
if (prv == 0) return ERR3;
if (n_play)
{
snd_pcm_poll_descriptors_revents (driver->play_parm.handle, pfd, n_play, &rev);
if (rev & POLLERR) return ERR4;
if (rev & POLLOUT) n_play = 0;
}
if (n_capt)
{
snd_pcm_poll_descriptors_revents (driver->capt_parm.handle, pfd + n_play, n_capt, &rev);
if (rev & POLLERR) return ERR5;
if (rev & POLLIN) n_capt = 0;
}
}
return 0;
--
FA

Lascia la spina, cogli la rosa.
Clemens Ladisch
2006-11-09 08:30:25 UTC
Permalink
Post by Fons Adriaensen
Post by Clemens Ladisch
Post by Fons Adriaensen
In that case, how can one test if *all* pollfd for a given
pcm are ready ?
You cannot. The state of the file descriptors is not necessarily
related to the state of the PCM device (which is why this function
exists).
So a loop waiting for both capture and playback being ready
[...]
Yes. The various snd_pcm_poll* functions just make the descriptors look
like a single poll descriptor. The logic should always be the same as
if it were using a single fd.


Regards,
Clemens

James Courtier-Dutton
2006-11-01 20:55:03 UTC
Permalink
Post by lemmel
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
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
lemmel
2006-11-01 21:17:19 UTC
Permalink
Post by James Courtier-Dutton
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
Clemens Ladisch
2006-11-02 08:44:43 UTC
Permalink
Post by lemmel
The sound was always troncated (even with finished software such as xmms,
amarok),
Were there samples missing at the beginning or at the end?
Post by lemmel
and even randomly truncated,
What do you mean with "randomly"?

What sound card/kernel version/ALSA version are you using?


Regards,
Clemens
lemmel
2006-11-02 17:55:19 UTC
Permalink
Post by Clemens Ladisch
Were there samples missing at the beginning or at the end?
At the end
Post by Clemens Ladisch
Post by lemmel
and even randomly truncated,
What do you mean with "randomly"?
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.
Post by Clemens Ladisch
What sound card/kernel version/ALSA version are you using?
see an another post of mine.
James Courtier-Dutton
2006-11-02 20:56:54 UTC
Permalink
Post by lemmel
Post by Clemens Ladisch
Were there samples missing at the beginning or at the end?
At the end
Post by Clemens Ladisch
Post by lemmel
and even randomly truncated,
What do you mean with "randomly"?
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.
Post by Clemens Ladisch
What sound card/kernel version/ALSA version are you using?
see an another post of mine.
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.
James Courtier-Dutton
2006-11-02 21:04:14 UTC
Permalink
Post by James Courtier-Dutton
Post by lemmel
Post by Clemens Ladisch
Were there samples missing at the beginning or at the end?
At the end
Post by Clemens Ladisch
Post by lemmel
and even randomly truncated,
What do you mean with "randomly"?
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.
Post by Clemens Ladisch
What sound card/kernel version/ALSA version are you using?
see an another post of mine.
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.
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
lemmel
2006-11-02 21:50:55 UTC
Permalink
Post by James Courtier-Dutton
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 :-)
Post by James Courtier-Dutton
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 :-) )
lemmel
2006-11-02 09:33:28 UTC
Permalink
Post by Clemens Ladisch
Were there samples missing at the beginning or at the end?
At the end
Post by Clemens Ladisch
Post by lemmel
and even randomly truncated,
What do you mean with "randomly"?
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.
Post by Clemens Ladisch
What sound card/kernel version/ALSA version are you using?
see an another post of mine.
Jens M Andreasen
2006-11-02 19:58:37 UTC
Permalink
Post by lemmel
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?
--
Paul Davis
2006-11-02 20:09:56 UTC
Permalink
Post by Jens M Andreasen
Post by lemmel
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 )
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.
Kjetil S. Matheussen
2006-11-02 23:06:37 UTC
Permalink
Post by lemmel
Post by Kjetil S. Matheussen
Only the oss modules in the linux kernel are deprecated. Programs using
the OSS api will still continue to work, currently most importantly
because of the oss emulation module in alsa.
I knew that the oss module was deprecated, and I infered that using the OSS
mecanism was too deprecated :-P. Are sure [1]?
Hmm, well, who decides... I think its pretty safe to write code for OSS
and be sure it will work for a long time. Maybe longer than code
written for ALSA as well, who knows.
Post by lemmel
Post by Kjetil S. Matheussen
If you should choose between alsa and oss, and the oss version works
just as well, or better than the alsa version, choose oss, because its a
more portable API than alsa.
What do you mean by "the oss version works just as well, or better than the
alsa version" ?
Thats a liberal quote...
But sorry, I don't think I can write what I ment any clearer... (well, you
can remove the comma after "well", but thats as clear as I can make it,
english is not my native language either. :-) )
Post by lemmel
Post by Kjetil S. Matheussen
However, if I were you, I would use sndlib, portaudio, jack, or some other
higher level audio input/output library instead of oss or alsa.
Well, all the files, that I will play, will have the same charactistics, do I
really need to bother with an hi-level API [2] ?
Why not?
Post by lemmel
[1] I noticed that a lot of applications still use OSS, and I thought it was
because the migration to ALSA was too complex.
That might be one reason. But if it works well with OSS, thats often good
enough. Its a shame it sometimes is hard to make OSS programs work with
jack though, but thats a problem that goes for alsa programs as well.
(Actually, its worse with alsa programs.)
Post by lemmel
[2] Futhermore I am afraid that an hi-level API will produce time drifts in
the playing.
No, I don't think so. Many people use portaudio, it could be your best
choise.
Paul Winkler
2006-11-03 15:02:39 UTC
Permalink
<delurk>
regarding portability...
portaudio?
</delurk>
--
Paul Winkler
http://www.slinkp.com
Jens M Andreasen
2006-11-04 03:43:25 UTC
Permalink
Post by Paul Winkler
<delurk>
regarding portability...
portaudio?
</delurk>
You mean, as in overhead next to none? Could be ...
--
lemmel
2006-11-05 08:45:41 UTC
Permalink
Thanks for all of your mails, I collected a lot of information :-)

Bye !
Continue reading on narkive:
Loading...