1 Nov
2006
1 Nov
'06
11:54 a.m.
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
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 ?
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.
1 Nov
1 Nov
5:32 p.m.
Le mercredi 01 novembre 2006 16:51, Kjetil S. Matheussen a écrit :
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]?
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" ?
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.
6:25 p.m.
On Wed, 2006-11-01 at 22:32 +0100, lemmel wrote:
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.
2 Nov
2 Nov
1:52 p.m.
Le mercredi 01 novembre 2006 23:20, Paul Davis a écrit :
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.
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.
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.
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 ?
4:09 p.m.
On Thu, 02 Nov 2006 18:52:42 +0100
lemmel <lem0mel(a)gmail.com> wrote:
Have you tried playing your file with the simple aplay command ?
$ aplay test.wav
It works fine here.
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
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. 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 ?
5:26 p.m.
Le jeudi 02 novembre 2006 21:06, David a écrit :
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 ??!!!
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" ?
8:09 p.m.
On Thu, 02 Nov 2006 22:26:04 +0100
lemmel <lem0mel(a)gmail.com> wrote:
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
Le jeudi 02 novembre 2006 21:06, David a écrit :
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.
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 ??!!! 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" ? 
1:20 p.m.
New subject: [linux-audio-dev] OSS will be back (was Re: alsa, oss , efficiency?)
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
lemmel wrote:
Le mercredi 01 novembre 2006 16:51, Kjetil S.
Matheussen a écrit :
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]?
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" ?
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.
3:44 p.m.
New subject: [linux-audio-dev] Re: OSS will be back (was Re: alsa, oss , efficiency?)
Le jeudi 02 novembre 2006 15:51, vous avez écrit :
Hi folks,
Hi and thanks for the mail :-)
[...]
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 ?
Without this
developers would stick with OSS which is several magnitudes easier API
to use.
Can you justify your point ?
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 )
4:02 p.m.
New subject: [linux-audio-dev] OSS will be back
Hannu Savolainen <hannu(a)opensound.com> writes:
[...]
Date: Tue, 03 Apr
2001 16:15:53 -0400
To: LAD <linux-audio-dev(a)ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] efficient non-blocking writes to /dev/dsp
Message-Id: <200104032013.QAA29210(a)renoir.op.net
In message <3ACA1FE4.B8E4EBE8(a)pp.htv.fi>you write:
>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
[...]
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.
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 <pbd(a)Op.Net 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"
10:42 p.m.
New subject: [linux-audio-dev] OSS will be back
On 11/3/06, Josef Jurek <jurek(a)cs.uchicago.edu> wrote:
Hannu Savolainen <hannu(a)opensound.com> writes:
[...]
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
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.
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
ALSA: hackers
3 Nov
3 Nov
3:29 a.m.
New subject: [linux-audio-dev] OSS will be back
On Fri, 2006-11-03 at 13:42 +1100, Loki Davison wrote:
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?
3:37 a.m.
New subject: [linux-audio-dev] OSS will be back
On 11/3/06, Jens M Andreasen <jens.andreasen(a)chello.se> wrote:
On Fri, 2006-11-03 at 13:42 +1100, Loki Davison
wrote:
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
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?
3:51 a.m.
New subject: [linux-audio-dev] OSS will be back
On Fri, Nov 03, 2006 at 06:37:13PM +1100, Loki Davison wrote:
On 11/3/06, Jens M Andreasen
<jens.andreasen(a)chello.se> wrote:
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.
On Fri, 2006-11-03 at 13:42 +1100, Loki Davison
wrote:
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. 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? 
12:39 p.m.
New subject: [linux-audio-dev] OSS will be back
On Fri, 2006-11-03 at 08:53 +0100, Fons Adriaensen wrote:
[...]
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
12:52 p.m.
New subject: [linux-audio-dev] OSS will be back
Le 3 nov. 06 à 17:39, Simon Jenkins a écrit :
On Fri, 2006-11-03 at 08:53 +0100, Fons Adriaensen
wrote:
c) or move to a 2 threads model: one for RT audio, one for
notification event handling
Stephane
[...]
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
1:16 p.m.
New subject: [linux-audio-dev] OSS will be back
On Fri, 2006-11-03 at 17:50 +0100, Stéphane Letz wrote:
Le 3 nov. 06 à 17:39, Simon Jenkins a écrit :
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
On Fri, 2006-11-03 at 08:53 +0100, Fons
Adriaensen wrote:
c) or move to a 2 threads model: one for RT audio, one for
notification event handling [...]
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
Stephane
1:21 p.m.
New subject: [linux-audio-dev] OSS will be back
Le 3 nov. 06 à 18:16, Simon Jenkins a écrit :
On Fri, 2006-11-03 at 17:50 +0100, Stéphane Letz
wrote:
jackdmp is c) already.
Stephane
Le 3 nov. 06 à 17:39, Simon Jenkins a écrit :
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
On Fri, 2006-11-03 at 08:53 +0100, Fons
Adriaensen wrote:
c) or move to a 2 threads model: one for RT audio, one for
notification event handling [...]
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
Stephane
1:08 p.m.
New subject: [linux-audio-dev] OSS will be back
On Fri, Nov 03, 2006 at 04:39:18PM +0000, Simon Jenkins wrote:
On Fri, 2006-11-03 at 08:53 +0100, Fons Adriaensen
wrote:
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.
[...]
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.
1:55 p.m.
New subject: [linux-audio-dev] OSS will be back
On Fri, 2006-11-03 at 18:37 +1100, Loki Davison wrote:
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)
Loki
--
9:56 p.m.
New subject: [linux-audio-dev] OSS will be back
On 11/4/06, Jens M Andreasen <jens.andreasen(a)chello.se> wrote:
On Fri, 2006-11-03 at 18:37 +1100, Loki Davison
wrote:
cat thing.au > /dev/dsp works on some systems. I'm not saying it makes
total sense though.
Loki
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)
Loki
--
6 Nov
6 Nov
6:46 a.m.
New subject: [linux-audio-dev] OSS will be back
Josef Jurek wrote:
"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.
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
2:36 p.m.
New subject: [linux-audio-dev] OSS will be back
On Mon, 2006-11-06 at 12:46 +0200, Hannu Savolainen wrote:
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
Josef Jurek wrote:
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.
"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. 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. 
3 Nov
3 Nov
11:52 p.m.
New subject: [linux-audio-dev] OSS will be back (was Re: alsa, oss , efficiency?)
On Thu, 2006-11-02 at 16:51 +0200, Hannu Savolainen wrote:
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-
6 Nov
6 Nov
2:39 p.m.
New subject: [linux-audio-dev] OSS will be back (was Re: alsa, oss , efficiency?)
On Thu, 2006-11-02 at 16:51 +0200, Hannu Savolainen wrote:
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
5:38 p.m.
New subject: [linux-audio-dev] OSS will be back (was Re: alsa, oss , efficiency?)
On Mon, Nov 06, 2006 at 01:39:43PM -0500, Lee Revell wrote:
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
6:27 p.m.
New subject: [linux-audio-dev] OSS will be back (was Re: alsa, oss , efficiency?)
On Mon, 2006-11-06 at 16:38 -0500, Paul Winkler wrote:
On Mon, Nov 06, 2006 at 01:39:43PM -0500, Lee Revell
wrote:
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
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.
8:29 p.m.
New subject: [linux-audio-dev] OSS will be back (was Re: alsa, oss , efficiency?)
Paul Davis wrote:
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.
7 Nov
7 Nov
10:12 a.m.
New subject: [linux-audio-dev] OSS will be back (was Re: alsa, oss , efficiency?)
James Courtier-Dutton wrote:
Paul Davis wrote:
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
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. 
11:39 a.m.
New subject: [linux-audio-dev] OSS will be back (was Re: alsa, oss , efficiency?)
Dne úterý 07 listopad 2006 00:29 James Courtier-Dutton napsal(a):
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
6 Nov
6 Nov
8:41 p.m.
New subject: [linux-audio-dev] OSS will be back (was Re: alsa, oss , efficiency?)
Paul Davis wrote:
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
7 Nov
7 Nov
10:57 a.m.
New subject: [linux-audio-dev] OSS will be back (was Re: alsa, oss , efficiency?)
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.
12:32 p.m.
New subject: [linux-audio-dev] OSS will be back (was Re: alsa, oss , efficiency?)
On Tue, Nov 07, 2006 at 07:56:52AM -0700, Garett Shulman wrote:
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
12:42 p.m.
New subject: [linux-audio-dev] OSS will be back (was Re: alsa, oss , efficiency?)
On Tue, 2006-11-07 at 16:54 +0000, John Rigg wrote:
On Tue, Nov 07, 2006 at 07:56:52AM -0700, Garett
Shulman wrote:
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
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
8:20 p.m.
New subject: [linux-audio-dev] OSS will be back (was Re: alsa, oss , efficiency?)
Lee Revell wrote:
On Tue, 2006-11-07 at 16:54 +0000, John Rigg wrote:
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
On Tue, Nov 07, 2006 at 07:56:52AM -0700, Garett
Shulman wrote:
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
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.
8 Nov
8 Nov
9:06 a.m.
New subject: [linux-audio-dev] OSS will be back (was Re: alsa, oss , efficiency?)
On Wed, Nov 08, 2006 at 12:20:42AM +0000, James Courtier-Dutton wrote:
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.
9:12 a.m.
New subject: [linux-audio-dev] OSS will be back (was Re: alsa, oss , efficiency?)
Fons Adriaensen wrote:
On Wed, Nov 08, 2006 at 12:20:42AM +0000, James
Courtier-Dutton wrote:
Applications must not look at ALSA's pollfds, they must use
snd_pcm_poll_descriptors_revents() instead.
Regards,
Clemens
The current jackd skips a step in the processing
of the poll events.
Basically what happens comes down to (ignoring error
checking and timeouts):
- The set of pollfd is poll()'ed until all are ready.
9:22 a.m.
New subject: [linux-audio-dev] OSS will be back (was Re: alsa, oss , efficiency?)
On Wed, Nov 08, 2006 at 02:12:09PM +0100, Clemens Ladisch wrote:
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 wrote:
Basically what
happens comes down to (ignoring error
checking and timeouts):
- 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.
10:39 a.m.
New subject: [linux-audio-dev] snd_pcm_poll_descriptors_revents() question
On Wed, Nov 08, 2006 at 02:24:30PM +0100, Fons Adriaensen wrote:
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.
12:59 p.m.
New subject: [linux-audio-dev] snd_pcm_poll_descriptors_revents() question
Fons Adriaensen wrote:
On Wed, Nov 08, 2006 at 02:24:30PM +0100, Fons
Adriaensen wrote:
It returns one revents value for the PCM device.
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? 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
2:45 p.m.
New subject: [linux-audio-dev] snd_pcm_poll_descriptors_revents() question
On Wed, Nov 08, 2006 at 05:58:40PM +0100, Clemens Ladisch wrote:
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.
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).
9 Nov
9 Nov
4:30 a.m.
New subject: [linux-audio-dev] snd_pcm_poll_descriptors_revents() question
Fons Adriaensen wrote:
On Wed, Nov 08, 2006 at 05:58:40PM +0100, Clemens
Ladisch wrote:
So a loop waiting for both capture and playback being ready
could be something like (cut down to the bare minimum):
[...]
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
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).
6535
days inactive
6543
days old
linux-audio-dev@lists.linuxaudio.org
41 comments
22 participants
participants (22)
-
Clemens Ladisch -
Ctirad Fertr -
Dave Robillard -
David -
Fernando Lopez-Lezcano -
Fons Adriaensen -
Garett Shulman -
Hannu Savolainen -
James Courtier-Dutton -
Jens M Andreasen -
John Rigg -
jurek＠cs.uchicago.edu -
Kjetil S. Matheussen -
Lee Revell -
lemmel -
Loki Davison -
Patrick Shirkey -
Paul Davis -
Paul Winkler -
Pieter Palmers -
Simon Jenkins -
Stéphane Letz