The ALSA Situation

The ALSA Situation

[Eugenia Loli-Queru]

Hi,
I have outlined here the mixing problem of Alsa/OSS (read point #4):
http://www.osnews.com/story.php?news_id=8823

I am writing to express my dissapointment over the piss poor desktop 
experience I get out of 2 of my PCs because of this problem (and I know that 
there are actually... millions like me as these ac97 onboard cards are 
everywhere these days). When the alsa driver knows that there is no hardware 
mixing, a software one should be created automatically, and it should be 
100% transparent to all alsa/oss applications or other kde/gnome mixers. It 
should behave like hardware mixing was there all along.

You see, I have already created the dmix plugin utter crap, and LD_PRELOADed 
the aoss wrapper and have the .asoundrc file in place (and esd, arts, 
gstreamer, mplayer and xmms configured to use the new "default" alsa 
device). But even after all this work to figure out how to do all that (it 
literally took me 2 days of googling and trying to figure out the black 
magic of alsa scripting) there are too many other sound apps that simply 
don't obey the dmix plugin. There are apps that they won't even launch until 
I press "stop" on xmms! Sometimes I even forget that I have launched them, 
and then I stop xmms, and then sudenly, hours later, the app that was 
blocked before, it would popup in my face! You call this good usability?

Yes, you can claim that some "apps are broken and they don't use the alsa 
api properly". But I say this to you: if a framework allows for such kinds 
of problems, then the framework itself is broken, not the apps. Mixing is 
something that the apps should be getting automatically from ALSA, the 
developers should not add code to their apps to allow for stuff like 
"changing the default alsa device". There should NOT be, EVER, an error like 
"the sound card is used by another app". If this happens, it's a failure of 
the media framework, NOT the failure of the app (I have never,ever,ever,ever 
seen such an error on OSX or BeOS). Besides, when I email these devs to add 
support for alternative alsa devices, they reply "get another sound card". 
And how the heck am I going to get a new sound card for my laptop, I don't 
know (the problem is mostly with laptops, as these use these AC97 intel/via 
cards).

I believe that this is an important point for all Alsa developers to read, 
because I am not alone. Read the comments on that story I link, and you will 
see that many other people FULLY agree with me that playing one sound at a 
time when the sound card doesn't have a hardware mixer, is POOR Linux 
experience. It just kills the impression of the operating system.

I am sorry, but from my POV, this mixer situation should be a SHOWSTOPPER 
for alsa getting released out in the wild. I wouldn't imaging Be, Apple or 
Microsoft releasing an OS or update where some of their sound drivers didn't 
have mixing support. It is laughable in 2004 not having proper *transparent* 
mixing for both Alsa/OSS-emulation via the sound framework on a popular 
operating system, like Linux is. You replaced OSS for some arguably good 
reasons, but your solution is equally crappy from where I stand: default 
muting (!), no proper mixing, ultra-weird scripting that noone really 
understands, impossible to find out how to enable 5.1 surround (even if the 
driver is capable of it) etc...

Alsa should have been a completely transparent thing as far the user is 
concerned. Alsa is a framework, and so only developers should be messing 
with it, not users. If the user needs to unmute the PCM, or write alsa 
scripts to get some *basic* functionality, then the Alsa project has already 
failed. Have you ever heard of Windows users talk about "GDI"? No. Why? 
Because they don't have to. It just works. Same thing on Linux, Alsa or X11 
are things that users should not even know what they are. These should just 
work. Let the users worry about bugs or problems in the higher level skirts 
of a Linux distro, not the frameworks.

I am sorry if I sound a bit  angry over this, but I spent days trying to get 
more than one app to use the sound card at the same time (plus dmix would 
still not work properly with all apps), and I know that there are many-many 
others like me, and I am so extremely surprised that the Alsa project hasn't 
found a better solution for the problem after 4-5 years of development.

Rgds,
Eugenia



-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click

Re: The ALSA Situation

[Paul Davis]

>I am sorry, but from my POV, this mixer situation should be a SHOWSTOPPER 
>for alsa getting released out in the wild. I wouldn't imaging Be, Apple or 
>Microsoft releasing an OS or update where some of their sound drivers didn't 
>have mixing support. It is laughable in 2004 not having proper *transparent* 

Actually, if you used ASIO drivers on Windows or MacOS-preX, you would
find that many drivers did not support simultaneous access by multiple
applications.

>Alsa should have been a completely transparent thing as far the user is 
>concerned. Alsa is a framework, and so only developers should be messing 
>with it, not users. If the user needs to unmute the PCM, or write alsa 
>scripts to get some *basic* functionality, then the Alsa project has already 
>failed. Have you ever heard of Windows users talk about "GDI"? No. Why? 

Your analogy and complaints have some real merit to them. But I think
you may not be aware of an important difference that affects your
comparisons. Until very recently, and depending on who you talk to,
still to this day, the default Windows audio drivers are useless for
the needs of musicians and pro-audio users. Consequently, there is an
entirely different set of drivers that have existed (ASIO, GDIF and
others) specifically to get around these problems. For some people,
the new WDM drivers are acceptable for both consumer audio and high
end audio apps, but not all.

The situation on MacOS is, in some ways, analogous to the one on
Linux. Apple completely abandoned their old audio API when they moved
to OS X, and forced all developers to move to a radically new API
(CoreAudio) that in many cases required a complete redesign of
applications. This is one of the reasons why many audio apps for MacOS
took 1-2 years to be ported to OSX. CoreAudio is very nice, and was
the inspiration for JACK.

ALSA has attempted to provide a single driver framework for the kinds
of devices used by pro-audio people all the way down to consumer
stereo and 5.1 devices. It has been very successful at the lowest
levels, but it is true that it has failed to provide adequate
user-space and user-level tools, configuration management and
documentation. 

On the bright side, ALSA has not forced a radical level of application
design changes on developers, but has enabled consistency across all
kinds of hardware. Many audio developers have chosen to use JACK,
which *does* impose a major change from OSS, though most of these apps
are music/pro-audio apps, not everyday desktop tools. There is
increasing interest in using JACK in more of desktop role, but there
are some significant technical issues to be solved before that could
happen. JACK allows much more than just soundcard sharing, it allows
apps to route audio to each other.

>others like me, and I am so extremely surprised that the Alsa project hasn't 
>found a better solution for the problem after 4-5 years of development.

What might (and should) suprise you more is that ALSA has, during the
last 4-5 years, never consisted of more than 2 full time
developers. It is very, very difficult with that level of manpower to
accomplish the kinds of things you want to see. People in and around
the project have hoped that the incorporation of ALSA into 2.6 would
lead to a major rise in the number of developers working on ALSA. It
has helped to increase the number of bugfixers, but AFAIK it has had
little impact on the level of development activity for user-level
tools and utilities.

I don't want to try to make excuses for the state of ALSA at the
user-level. I myself, as a developer, am very frustrated by the lack
of a sufficiently abstract mixer API for the work I try to do. But
ALSA isn't going anywhere in the direction you and many others need it
to without some more people *really* getting into the development
team. No matter how much Jaroslav might agree with all that you've
said, there are not enough hours in the day (his or yours) to make
that happen.

--p



-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click

Re: The ALSA Situation

[Eugenia Loli-Queru]

>. But
> ALSA isn't going anywhere in the direction you and many others need it
> to without some more people *really* getting into the development
> team. No matter how much Jaroslav might agree with all that you've
> said, there are not enough hours in the day (his or yours) to make
> that happen.

Why not move to OSS 4.x to the Linux kernel then (which is afaik actively 
developed), when it's out? If alsa is the failure you are describing, with 
no extra devs working on it, I see absolutely no reason for it to be used as 
default in the kernel and drive more developers to use it instead of OSS 
(and also develop an alsa 1.0.2 wrapper in order to keep compatibility with 
alsa apps so far). Sure, OSS is not GPL, but who cares, if it does the job 
at the end of the day? I for one, only care for things to work as I expect 
them too, I don't care about the politicalities.

BTW, in my previous email, I forgot to mention two more huge problems with 
alsa:
1. again with the mixing thing, browsers will stall and not load a flash 
webpage if another app uses the sound device. It's tragic to see firefox not 
loading www.macromedia.com for example, just because xmms is playing a 
song...
2. This: http://www.osnews.com/img/6443/audio.png Check the clean and 
logical OSS options and then check the endless alsa ones (my monitor was not 
wide enough to fit them all). Why things like that are not cleaned up? (it's 
not gnome's volume control fault btw, I asked the developer, he said it's 
Alsa's)

Rgds,
Eugenia 



-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click

Re: The ALSA Situation

[Paul Davis]

>Why not move to OSS 4.x to the Linux kernel then (which is afaik actively 

Because OSS is a limitation for developers. It has *no* consistent API
for handling devices with many different designs. The debate over the
OSS API and the ALSA API has already been settled. And anyway, only a
minority anybody are writing new apps for either of these APIs. Most
people use abstract/portability layers such as the KDE/Gnome audio
APIs, or JACK or PortAudio.

>developed), when it's out? If alsa is the failure you are describing, with 

i did not say it was a failure - please do not twist my words in that
way. it has been very successful at the driver level, but there is
still a lot more work to be done in terms of user tools. 

>no extra devs working on it, I see absolutely no reason for it to be used as 
>default in the kernel and drive more developers to use it instead of OSS 

the reason is that OSS' design is inadequate for the range of h/w that
is now available. there is no consistent and efficient way to address 
different kinds of h/w, so apps have to be written with a specific h/w
design in mind. i've had this debate endlessly with people over the
last several years. some OSS fans (including 4Front people) continue
to insist that OSS can do the job, but I have never been persuaded
that I could use the OSS API to write an app that would run on both a
Hammerfall DSP and a SoundBlaster or AC97 consumer card with the
appropriate efficiency in both cases.

>(and also develop an alsa 1.0.2 wrapper in order to keep compatibility with 
>alsa apps so far). Sure, OSS is not GPL, but who cares, if it does the job 

who cares? Linus cares, for a start, and he's just one of thousands.

>BTW, in my previous email, I forgot to mention two more huge problems with 
>alsa:
>1. again with the mixing thing, browsers will stall and not load a flash 
>webpage if another app uses the sound device. It's tragic to see firefox not 
>loading www.macromedia.com for example, just because xmms is playing a 
>song...

this is not a different problem from the ones you mentioned. its the
same problem.

>2. This: http://www.osnews.com/img/6443/audio.png Check the clean and 
>logical OSS options and then check the endless alsa ones (my monitor was not 
>wide enough to fit them all). Why things like that are not cleaned up? (it's 
>not gnome's volume control fault btw, I asked the developer, he said it's 

because ALSA started out trying to represent the *full* capabilities
of the hardware mixer, rather than starting from a small common subset
and then later figuring out how to manage wildly new/different
capabilities in new hardware. how would OSS represent a matrix mixer?
how would it represent a device with new types of switches that don't
exist in a "simple" mixer?

it has been realized that user-space is in dire need of a simple mixer
layer, and it has been discussed several times. but once again, even
if the path forward is clear, it needs someone to actually have the
time to do the work.

--p


-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click

Re: The ALSA Situation

[Lee Revell]

On Tue, 2004-11-09 at 18:38 -0800, Eugenia Loli-Queru wrote:
> 2. This: http://www.osnews.com/img/6443/audio.png Check the clean and 
> logical OSS options and then check the endless alsa ones (my monitor was not 
> wide enough to fit them all). Why things like that are not cleaned up? (it's 
> not gnome's volume control fault btw, I asked the developer, he said it's 
> Alsa's)

Bullshit.  If ALSA provides too many controls then GNOME volume control
should abstract them a bit.  For example, use separate tabs for playback
and capture, like alsamixer, or leave some elements out, instead of
blithely cramming every mixer element into one tab without regard to
whether it will fit on screen or whether that mixer control SHOULD be
user visible.  Sorry, this is not ALSA's job. 

Lee



-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click

Re: The ALSA Situation

[Jaroslav Kysela]

On Tue, 9 Nov 2004, Eugenia Loli-Queru wrote:

> 1. again with the mixing thing, browsers will stall and not load a flash 
> webpage if another app uses the sound device. It's tragic to see firefox not 
> loading www.macromedia.com for example, just because xmms is playing a 
> song...

You can disable this feature - look for nonblock_open in
Documentation/sound/alsa/OSS-Emulation.txt . We follow posix by default,
the original OSS API does not.

> 2. This: http://www.osnews.com/img/6443/audio.png Check the clean and 
> logical OSS options and then check the endless alsa ones (my monitor was not 
> wide enough to fit them all). Why things like that are not cleaned up? (it's 
> not gnome's volume control fault btw, I asked the developer, he said it's 
> Alsa's)

We have API which won't be changed. It's only an abstraction level which
is missing in alsa-lib. Actually, all mixer controls are automatically
mapped from the driver to application which is not ideal for complex
hardware. I'm working on layer which will solve this issue.

Things are not tragic as you've described.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs


-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click

Re: The ALSA Situation

[Lee Revell]

On Wed, 2004-11-10 at 11:57 +0100, Jaroslav Kysela wrote:
> On Tue, 9 Nov 2004, Eugenia Loli-Queru wrote:
> 
> > 1. again with the mixing thing, browsers will stall and not load a flash 
> > webpage if another app uses the sound device. It's tragic to see firefox not 
> > loading www.macromedia.com for example, just because xmms is playing a 
> > song...
> 
> You can disable this feature - look for nonblock_open in
> Documentation/sound/alsa/OSS-Emulation.txt . We follow posix by default,
> the original OSS API does not.
> 

I would expect that most distros want to ship with this disabled.
Please look into how your distro sets this by default and file a bug
report.

<rant>

Really, it is up to the distros to ship with a sane ALSA config.  The
ALSA team provides a powerful low level API to access sound hardware; it
is the job of the distros to decide on the most useful config for their
their users and ship as such.  You cannot expect the ALSA guys to
anticipate the needs of every class of user.  This is like expecting the
kernel devs to come up with a one-size-fits-all Kconfig - the whole
reason it is configurable is because different users need different
defaults.  There is such a thing, look at the default Red Hat or Debian
kernel config, but that configuration was arrived at by combining
feedback from countless users.  They are different because those distros
have different user bases.  My point is, you can't know it a priori.

For example the muted-by-default issue - if you don't like this then
complain to Red Hat or whoever is shipping with the mixer controls
muted.  For a desktop oriented, use-it-out-of-the-box distro this _is_ a
bug.  For many other applications (like pro audio) you WANT everything
muted by default - better to have to find the volume control than
destroy 100s of ppls hearing with a blast of noise through a PA.  It's
not reasonable to expect this to be solved at the ALSA level because
there is no magic default that works for everyone.

</rant>

Lee



-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click

Re: The ALSA Situation

[Linus Torvalds]

[ Eugenia removed ]

On Wed, 10 Nov 2004, Jaroslav Kysela wrote:
> 
> You can disable this feature - look for nonblock_open in
> Documentation/sound/alsa/OSS-Emulation.txt . We follow posix by default,
> the original OSS API does not.

That's a load of BULL.

There is nothing in POSIX that says that you should block for the sound 
device to be non-busy. Claiming that this is "because of posix" is clearly 
totally mis-understanding what posix is all about.

First off, POSIX doesn't even specify that kind of detail, and second, if 
you actually think about it for a second, you will notice that no other 
subsystem actually behaves like you claim posix requires. If you open a 
ttyu device, it won't block until the tty is "free". It just opens it. 
Similarly, if you open a disk device, it won't block until there are no 
other users. It just opens it.

There is _one_ special case, which is for FIFO's, and that one is that you
should open the fifo even if there is _no_ other reader/writer, ie it's
explicitly exactly the _other_ way around from what you claim.

In fact, what O_NONBLOCK means in general is to set a flag that says that
subsequent reads and writes are non-blocking. But the open() itself
succeeds, _it_ doesn't block.

On block devices, O_NONBLOCK also is a way to say "don't try to do any 
device discovery", ie you can do a O_NONBLOCK open on a removable disk 
that doesn't even have any media in it. Again, this has _nothing_ to do 
with whether the device is "busy" or not.

I don't care whether Eugenia has a point in her complaints or not (hey,
it's a usability issue, you can make that decision yourself), but I _do_
care about technical people making totally bogus arguments. And Jaroslav,
that "posix says so" argument is totally and utterly bogus.

So if that's really the reason for "nonblock_open", then I would strongly
suggest that you default to that stupid feature _off_. Anybody who really
wants the blocking opens (sounds like nobody really would) could then turn
it on as desired.

Short summary:

 - O_NONBLOCK should generally be seen as just setting the O_NONBLOCK flag 
   "early" (ie it's conceptually equivalent to doing a "F_SETFL" fcntl 
   before the open. It _may_ affect the open itself, but when it does, it 
   is generally considered to mean that you can open something that isn't 
   even _reachable_.

 - POSIX doesn't say anything much about its behaviour, except for named 
   pipes, where it says the total reverse of what ALSA does. But that 
   doesn't actually mean anything, because even that is very much defined 
   as a special case by POSIX.

In other words, if your sound card had a sensor saying "speakers connected 
or not", then O_NONBLOCK might say "we'll open the damn thing even if 
there are no speakers". But it definitely doesn't say anything about other 
users.

Off on a tangent: some other device drivers have a notion of "exclusive
open", which says that only one process can open the device at a time. For 
example, something like a tape driver generally only accepts a single open 
at a time. But with those kinds of drivers, they do NOT wait for other 
opens to go away: they return EBUSY.

So please change this behaviour, or at least stop blaming POSIX for the
braindamage. Either return EBUSY if you really want exclusion, or just
allow concurrent access.

In general, it is almost universally felt that concurrent access is better
than EBUSY, unless there are fundamental reasons why it can't work (and I
think everybody understands what the fundamental reasons are for a tape
device. For a sound device, inability to do mixing might well fall under
the same heading).

Please?

			Linus


-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click

Re: The ALSA Situation

[Giuliano Pochini]

On Tue, 9 Nov 2004, Eugenia Loli-Queru wrote:

> You see, I have already created the dmix plugin utter crap, and LD_PRELOADed
> the aoss wrapper and have the .asoundrc file in place (and esd, arts,
> gstreamer, mplayer and xmms configured to use the new "default" alsa
> device). But even after all this work to figure out how to do all that (it
> literally took me 2 days of googling and trying to figure out the black
> magic of alsa scripting) there are too many other sound apps that simply
> don't obey the dmix plugin. There are apps that they won't even launch until
> I press "stop" on xmms! Sometimes I even forget that I have launched them,
> and then I stop xmms, and then sudenly, hours later, the app that was
> blocked before, it would popup in my face! You call this good usability?

Maybe you can post here on in the users list your config to see if there's
something wrong. Someone could collect all these common problems and
publish a faq.

> Yes, you can claim that some "apps are broken and they don't use the alsa
> api properly". But I say this to you: if a framework allows for such kinds
> of problems, then the framework itself is broken, not the apps.

If an app does something in blocking mode on a busy resource, what do you
expect ?


> Mixing is
> something that the apps should be getting automatically from ALSA, the
> developers should not add code to their apps to allow for stuff like
> "changing the default alsa device".

Well, if you have two cards, you need a way to choose what card to use,
don't you ?


> You replaced OSS for some arguably good
> reasons, but your solution is equally crappy from where I stand: default
> muting (!), no proper mixing, ultra-weird scripting that noone really
> understands, impossible to find out how to enable 5.1 surround (even if the
> driver is capable of it) etc...

Default muted if a good thing. Perhaps you don't know that most studio
monitors have no volume control: they are at full power all the time.
Mixing depends on the hw. 5.1 (or even 8 channels) works fine here
just using aplay.


> Alsa should have been a completely transparent thing as far the user is
> concerned. Alsa is a framework, and so only developers should be messing
> with it, not users.

Yes, drivers should ship with their own sane .alsarc file... and I never
find the time.


> If the user needs to unmute the PCM, or write alsa
> scripts to get some *basic* functionality, then the Alsa project has already
> failed. Have you ever heard of Windows users talk about "GDI"? No. Why?
> Because they don't have to. It just works. Same thing on Linux, Alsa or X11
> are things that users should not even know what they are. These should just
> work. Let the users worry about bugs or problems in the higher level skirts
> of a Linux distro, not the frameworks.

This is not simple at all. There are a lot of things that cannot be
"translated" to something common. For exaple on cards like hdsp and Echo
Mia, if you want to change the volume of a stereo output you have to
change the volume of two columns of the mixer. You can solve the problem
by removing the mixer so the apps will see a simple volume knob. But I
don't think it's a good thing turing a good card into a sb clone :)
Jaroslav have some good ideas for this class of problems but the
development is slow due to lack of time.


--
Giuliano.


-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click

Re: The ALSA Situation

[Takashi Iwai]

At Wed, 10 Nov 2004 08:43:38 -0800 (PST),
Linus Torvalds wrote:
> 
> 
> [ Eugenia removed ]
> 
> On Wed, 10 Nov 2004, Jaroslav Kysela wrote:
> > 
> > You can disable this feature - look for nonblock_open in
> > Documentation/sound/alsa/OSS-Emulation.txt . We follow posix by default,
> > the original OSS API does not.
> 
> That's a load of BULL.
> 
> There is nothing in POSIX that says that you should block for the sound 
> device to be non-busy. Claiming that this is "because of posix" is clearly 
> totally mis-understanding what posix is all about.
 
I remember that it had been discussed some time ago in ALSA devel.

Rereading the definition at opengroup.org again, the following is
found about open() and O_NONBLOCK:

================================================================
O_NONBLOCK
    When opening a FIFO with O_RDONLY or O_WRONLY set:

        * If O_NONBLOCK is set, an open() for reading-only shall
          return without delay. An open() for writing-only shall
          return an error if no process currently has the file open
          for reading.  
        * If O_NONBLOCK is clear, an open() for reading-only shall
          block the calling thread until a thread opens the file for
          writing. An open() for writing-only shall block the calling
          thread until a thread opens the file for reading. 

    When opening a block special or character special file that
    supports non-blocking opens: 

        * If O_NONBLOCK is set, the open() function shall return
          without blocking for the device to be ready or
          available. Subsequent behavior of the device is
          device-specific.  
        * If O_NONBLOCK is clear, the open() function shall block the
          calling thread until the device is ready or available before
          returning. 

    Otherwise, the behavior of O_NONBLOCK is unspecified.
================================================================


... and opening the sound device corresponds to the second case.

IIRC, the above sentense is the only reason we did implement in such a
way during the developemt of ALSA drivers although we've known it's
not always convenient.  If the current implementation is some
misreading, I guess nobody won't refuse to correct the default
behavior as you wrote :)


BTW, this kind of "confusion" is found in the OSS drivers, too.
Some OSS drivers do like ALSA (blocking at open) while some don't.
This is also the reason we provide both behavior for OSS emulation
module by switching with a module parameter as a compromise.


Takashi


> First off, POSIX doesn't even specify that kind of detail, and second, if 
> you actually think about it for a second, you will notice that no other 
> subsystem actually behaves like you claim posix requires. If you open a 
> ttyu device, it won't block until the tty is "free". It just opens it. 
> Similarly, if you open a disk device, it won't block until there are no 
> other users. It just opens it.
> 
> There is _one_ special case, which is for FIFO's, and that one is that you
> should open the fifo even if there is _no_ other reader/writer, ie it's
> explicitly exactly the _other_ way around from what you claim.
> 
> In fact, what O_NONBLOCK means in general is to set a flag that says that
> subsequent reads and writes are non-blocking. But the open() itself
> succeeds, _it_ doesn't block.
> 
> On block devices, O_NONBLOCK also is a way to say "don't try to do any 
> device discovery", ie you can do a O_NONBLOCK open on a removable disk 
> that doesn't even have any media in it. Again, this has _nothing_ to do 
> with whether the device is "busy" or not.
> 
> I don't care whether Eugenia has a point in her complaints or not (hey,
> it's a usability issue, you can make that decision yourself), but I _do_
> care about technical people making totally bogus arguments. And Jaroslav,
> that "posix says so" argument is totally and utterly bogus.
> 
> So if that's really the reason for "nonblock_open", then I would strongly
> suggest that you default to that stupid feature _off_. Anybody who really
> wants the blocking opens (sounds like nobody really would) could then turn
> it on as desired.
> 
> Short summary:
> 
>  - O_NONBLOCK should generally be seen as just setting the O_NONBLOCK flag 
>    "early" (ie it's conceptually equivalent to doing a "F_SETFL" fcntl 
>    before the open. It _may_ affect the open itself, but when it does, it 
>    is generally considered to mean that you can open something that isn't 
>    even _reachable_.
> 
>  - POSIX doesn't say anything much about its behaviour, except for named 
>    pipes, where it says the total reverse of what ALSA does. But that 
>    doesn't actually mean anything, because even that is very much defined 
>    as a special case by POSIX.
> 
> In other words, if your sound card had a sensor saying "speakers connected 
> or not", then O_NONBLOCK might say "we'll open the damn thing even if 
> there are no speakers". But it definitely doesn't say anything about other 
> users.
> 
> Off on a tangent: some other device drivers have a notion of "exclusive
> open", which says that only one process can open the device at a time. For 
> example, something like a tape driver generally only accepts a single open 
> at a time. But with those kinds of drivers, they do NOT wait for other 
> opens to go away: they return EBUSY.
> 
> So please change this behaviour, or at least stop blaming POSIX for the
> braindamage. Either return EBUSY if you really want exclusion, or just
> allow concurrent access.
> 
> In general, it is almost universally felt that concurrent access is better
> than EBUSY, unless there are fundamental reasons why it can't work (and I
> think everybody understands what the fundamental reasons are for a tape
> device. For a sound device, inability to do mixing might well fall under
> the same heading).
> 
> Please?
> 
> 			Linus
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Sybase ASE Linux Express Edition - download now for FREE
> LinuxWorld Reader's Choice Award Winner for best database on Linux.
> http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/alsa-devel
> 


-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click

Re: The ALSA Situation

[Jaroslav Kysela]

On Wed, 10 Nov 2004, Linus Torvalds wrote:

> I don't care whether Eugenia has a point in her complaints or not (hey,
> it's a usability issue, you can make that decision yourself), but I _do_
> care about technical people making totally bogus arguments. And Jaroslav,
> that "posix says so" argument is totally and utterly bogus.

I see in all manual pages for open() on web these sentences:

  When opening a block special or character special file that supports 
  non-blocking opens, such as a terminal device:

    +  If neither O_NDELAY nor O_NONBLOCK is set, the open() function blocks
       until the device is ready or available.

    +  If O_NDELAY or O_NONBLOCK is set, the open() function returns without
       waiting for the device to be ready or available. Subsequent behavior
       of the device is device-specific.

The word 'available' clearly states the role of the O_NONBLOCK flag. There
is no specification if availability is restricted to hardware reasons.  
Applications can still break the busy-wait-loop using SIG_ALARM (or any
other signal).

Of course, if our interpretation is weak, then we can simply return to the
"standard" behaviour for the OSS API. While ALSA API documents this
feature and we use this flag for operation which cannot be substituted
easily from the applications (except replacing waiting for event with ugly
polling), I propose to leave the "blocking" behaviour for ALSA
applications.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs


-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click

Re: The ALSA Situation

[Linus Torvalds]

On Wed, 10 Nov 2004, Takashi Iwai wrote:
>
>         * If O_NONBLOCK is clear, the open() function shall block the
>           calling thread until the device is ready or available before
>           returning. 

They key here being "ready or available". but also common sense and, in 
the case of POSIX, existing practice.

The sound card IS available. It IS ready. It clearly is, since somebody
else can use it. It doesn't have any issues like "I must load the media"
or similar. 

Basically, the "ready or available" thing is about an issue of DEVICE
STATE. A device that is _not_ available is, for example, a tape robot that
doesn't have the right tape loaded yet. It needs to wait for the tape to
load. Or it might be a device that needs to load a device driver (think
"modprobe") or firmware in order to be "ready or available". Or it needs
to open a connection over the network. Or any number of actual things you 
need to do to make sure that the device is actually ready to be used.

And even then, if the "make it ready" requires human intervention, a
device will not just wait. It will tell the user with an error. So for
example, a tape robot that actually can load the tape itself will load the
tape (and wait until it is loaded), but a empty tape drive that needs the
user to load a tape will NOT just silently wait forever. It will tell the
user that it has no tape with an error code.

Somebody else having the device open does not make it "not available". It
might make it _busy_, but that's a totally different thing. That's what
you have EBUSY for.

Sure, you can try to read it some other way, but the fact is, such a
reading is not only totally nonsensical it is also clearly against
existing practices. Just look at pretty much ANY other character/block
special device. ttys, block devices, mice, you name it. If they have 
single-use restrictions, they return EBUSY, they don't wait.

		Linus


-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click

Re: The ALSA Situation

[Linus Torvalds]

On Wed, 10 Nov 2004, Jaroslav Kysela wrote:
> 
> Of course, if our interpretation is weak

It's not "weak". It's just totally unsupported by _anything_ but the most
perverse possible reading of POSIX. It's not supported by how other
devices behave (*), and it's quite frankly not in my opinion supported by
the wording in the document either. And it's pretty clearly not supported
by how people want or expect things to act.

		Linus

(*) POSIX is not a "new standard" either - it was created very much to
codify existing practices and avoid splintering UNIX more. So if you think
you can read the POSIX standard two different ways, and existing practices
imply one over the other, then that _is_ what it's about. The POSIX
committee very much avoided introducing new behaviour (and they documented
that too).

Sometimes they had to choose one implementation over another, and
sometimes when it was impossible to do they introduced a new interface to
make things unambiguous, but nowhere can I see how somebody thinks that
"ready and available" means "exclusive".

If the POSIX wording had meant "exclusive", it would _say_ "exclusive". It 
would not say "ready and available".


-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click

Re: The ALSA Situation

[Paul Davis]

>It's not "weak". It's just totally unsupported by _anything_ but the most
>perverse possible reading of POSIX. It's not supported by how other
>devices behave (*), and it's quite frankly not in my opinion supported by
>the wording in the document either. And it's pretty clearly not supported
>by how people want or expect things to act.

although its hard to disagree with your reading of it, do consider
this. with the current block-by-default behaviour, it is possible to
do cute things like queue up N invocations of a program that does not
use O_NONBLOCK and have them execute sequentially, each one starting
precisely as the previous one closes the device.

with the ebusy-by-default behaviour, there isn't a way that i can see
to get that behaviour, since O_BLOCK doesn't exist. the current design
allows both behaviours; EBUSY allows only one (ignoring stupid hacks
like looping on open+sleep).

of you course, you could argue that

----------------------------------------
#!/bin/sh

prog1
prog2
prog3
----------------------------------------

is all you need to execute programs sequentially in this
fashion. practically speaking, this is often true, but from a
theoretical perspective, device closing is very different from program
exit. 

--p


-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click

Re: The ALSA Situation

[Linus Torvalds]

On Wed, 10 Nov 2004, Paul Davis wrote:
> 
> although its hard to disagree with your reading of it, do consider
> this. with the current block-by-default behaviour, it is possible to
> do cute things like queue up N invocations of a program that does not
> use O_NONBLOCK and have them execute sequentially, each one starting
> precisely as the previous one closes the device.

If you actually think this is a useful feature, I would suggest trying to 
key it off O_EXCL or a new flag.

That said, I don't see why a regular open() that doesn't wait shouldn't 
act that way. I would suggest that "close()" wait for the buffer to drain, 
unless interrupted by a signal. Again, this is how all other streaming 
devices tend ot work - this is _not_ a new requirement.

So if you have

	#!/bin/sh
	prog1
	prog2
	prog3

and they all open the sound device, they _will_ be serialized by their
closes. This is exactly why the VFS layer calls "->flush()" on each close,
and "->release()" on the last close - so that people can have open->close
consistency, which is a _good_ thing.

NOTE! If you do flush on close, you should not wait forever until the
device is no longer busy. If another open keeps streaming data to the
device, you should definitely not wait for _that_ to stop.  The same way
that it's bad if an open() waits for an indeterminate long time, it's
wrong if a close() waits for a long time. You might even have a timeout,
in case of hw problems.  Others do the same thing.

As for actual concurrent opens (which the above is not), there are 
multiple options that are all perfectly reasonable:

 (a) returning EBUSY (simplest)
 (b) allowing "n" opens and retuning -EBUSY for "n+1", and mixing the data 
     (which basically boils down to (a) if "n" is 1). This would tend to 
     be one obvious way to go if the hw does mixing for you.
 (c) just using a common buffer (ie no mixing - you just write the data 
     sequentially, and the user _will_ notice). Anybody who wants mixing 
     would need to use an explicit mixing interface.

The (c) example above probably isn't as stupid as it sounds: it allows the
common case of intermixed "beeps" etc event notification, and it has the
advantage that when it doesn't work well, the user damn well notices
pretty much immediately. That may sound like a bad thing, but it's
actually a _good_ thing - if the user notices the problem, most people
will realize that the right answer is often "don't do that then".

I think that what really irritated Eugenia was how things didn't work in
pretty non-obvious ways (ie the "several hours later, the apps sprang to
life"). So (c) - while admittedly very very stupid - at least is broken in 
_obvious_ ways, rather than being broken in non-obvious ways.

Imagine a user that clicks on an icon to launch an application. What does
he/she/it do when the app doesn't start? Clicks again. And again. Until
bored. And then, five hours later, when xmms exits, you have a hundred
applications suddenly all starting up at the same time. THAT is
"non-obvious breakage".

The "mixing" approach is obviously likely to be the thing that most people 
want. Especially if coupled with "flush on close".

		Linus


-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click

Re: The ALSA Situation

[Paul Davis]

>That said, I don't see why a regular open() that doesn't wait shouldn't 
>act that way. I would suggest that "close()" wait for the buffer to drain, 
>unless interrupted by a signal. Again, this is how all other streaming 
>devices tend ot work - this is _not_ a new requirement.
>
>So if you have
>
>	#!/bin/sh
>	prog1
>	prog2
>	prog3
>
>and they all open the sound device, they _will_ be serialized by their
>closes. This is exactly why the VFS layer calls "->flush()" on each close,

i think you missed my point about program exit not being synonymous
with close(2). if prog1 closes the device but then does something else
for a while, prog2 doesn't run till prog1 exits (in the above shell
script). 

with the block-on-busy-open behaviour, prog2 runs but blocks on open
and then continues as soon as prog1 does the close(). with
EBUSY-on-busy and a script, prog2 doesn't run till prog1 exits.

btw, xmms is a sort-of relevant example of this. xmms opens and closes
the audio device several times during a typical use pattern, and
doesn't exit unless actually told explicitly to do so. so:

    xmms beep1
    otherprog beep2

would not actually do the right thing. one could fault xmms for this
behaviour, i suppose.

>Imagine a user that clicks on an icon to launch an application. What does
>he/she/it do when the app doesn't start? Clicks again. And again. Until
>bored. And then, five hours later, when xmms exits, you have a hundred
>applications suddenly all starting up at the same time. THAT is
>"non-obvious breakage".

100% agreed.

--p




-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click

Re: The ALSA Situation

[Hannu Savolainen]

On Wed, 10 Nov 2004, Linus Torvalds wrote:

> It's not "weak". It's just totally unsupported by _anything_ but the most
> perverse possible reading of POSIX. It's not supported by how other
> devices behave (*), and it's quite frankly not in my opinion supported by
> the wording in the document either. And it's pretty clearly not supported
> by how people want or expect things to act.
Thanks, Linus. I have to say I completely agree with you.

This block-on-open feature is used by /dev/audio in SunOS which may be
reason why ALSA and some of the OSS/Free drivers use it.

It has not been supported by "official" OSS and it will never be
supported in the future. The original reason was that this behaviour is
useless and totally undesirable.

However the main reason today is that average programmers will never ever
learn how to use it. They use O_NONBLOCK in open because they don't want
to wait. Unfortunately 9 programers out of 10 don't realize that O_NONBLOCK
must be turned off after open.

And sometimes it's so difficult explain to users what does the "Resource
temporarily unavailable" error mean. Some customers are so sure that it's
definitely caused by a bug in the driver. Or they may go to buy a new
sound card because some project deadline is approaching and the old one
doesn't have enough capacity for them.

So regardless of what POSIX or anything else says the blocking open
feature when the device is busy is total disater. It might be usefull with
slow tape drives that may need up to minutes to rewind the tape. But
waiting for some other application to close the device is stupid.

Best regards,

Hannu
-----
Hannu Savolainen (hannu@opensound.com)
http://www.opensound.com (Open Sound System (OSS))
http://www.compusonic.fi (Finnish OSS pages)
OH2GLH QTH: Karkkila, Finland LOC: KP20CM


-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click

Re: The ALSA Situation

[Linus Torvalds]

On Wed, 10 Nov 2004, Paul Davis wrote:
> 
> i think you missed my point about program exit not being synonymous
> with close(2). if prog1 closes the device but then does something else
> for a while, prog2 doesn't run till prog1 exits (in the above shell
> script). 

Yes. 

> with the block-on-busy-open behaviour, prog2 runs but blocks on open
> and then continues as soon as prog1 does the close().

No, prog wouldn't even have started until prog1 exited, so the behaviour 
would be exactly the same.

And if the programs put themselves in the background, well, then the order 
of them is totally undefined, so then prog2 might end up opening the sound 
device _before_ prog1 even got to it. So I really don't see your point, 
except as some very unlikely (and apparently totally broken) situation.

> btw, xmms is a sort-of relevant example of this. xmms opens and closes
> the audio device several times during a typical use pattern

So? It will still end up doing exactly the same waiting. It just does it 
at the close instead of at the open.

Maybe the timing is different, but does anybody really care?

If anything, I suspect that the "flush on close" should _not_ wait for the 
sound to have stopped, because you may have applications that open and 
close the thing, and you want the sound to be contiguous and you do _not_ 
want to hear popping. 

So to avoid the popping issue, I'd suggest that the "flush on close"  
doesn't actually wait for the sound to end, but it might wait until the
final sound fragment has been sent to the device. So hopefully the next 
app has a few milliseconds of time to re-open the stream and start filling 
the buffers again, so that you don't get any popping.

(Yeah, I haven't looked at what the granularity of mixing is that ALSA
supports, but I assume that once you've given a sound fragment to a
device, that channel doesn't end up mixing that fragment any more, so a 
sunsequent app would not _wait_ for the sound, but it's buffers wouldn't 
actually be heard until the previous fragment was done. At least that's 
one way of handling it).

		Linus


-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click

Re: The ALSA Situation

[James Courtier-Dutton]

Lee Revell wrote:
> On Tue, 2004-11-09 at 18:38 -0800, Eugenia Loli-Queru wrote:
> 
>>2. This: http://www.osnews.com/img/6443/audio.png Check the clean and 
>>logical OSS options and then check the endless alsa ones (my monitor was not 
>>wide enough to fit them all). Why things like that are not cleaned up? (it's 
>>not gnome's volume control fault btw, I asked the developer, he said it's 
>>Alsa's)
> 
> 
> Bullshit.  If ALSA provides too many controls then GNOME volume control
> should abstract them a bit.  For example, use separate tabs for playback
> and capture, like alsamixer, or leave some elements out, instead of
> blithely cramming every mixer element into one tab without regard to
> whether it will fit on screen or whether that mixer control SHOULD be
> user visible.  Sorry, this is not ALSA's job. 
> 
> Lee
> 

alsamixer only has separate tabs for playback and capture because 
someone spent time implementing it.

ALSA has a very good API for PCM audio. The plans are ready for creating 
a very good API for mixer. While the plans have been there for some time 
now, developer's time has not been available. Unluckily, the current 
underdevelopment of the mixer parts of ALSA are very much apparent to 
all users.

The work required to support so many different sound cards has been 
considerable.

So, if you ignore the current well understood problems with the mixer, 
the rest of ALSA is very good.

James


-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click

Re: The ALSA Situation

[Fernando Pablo Lopez-Lezcano]

On Wed, 2004-11-10 at 14:34, Linus Torvalds wrote:
> On Wed, 10 Nov 2004, Paul Davis wrote:
> > 
> > i think you missed my point about program exit not being synonymous
> > with close(2). if prog1 closes the device but then does something else
> > for a while, prog2 doesn't run till prog1 exits (in the above shell
> > script). 
> 
> Yes. 
> 
> > with the block-on-busy-open behaviour, prog2 runs but blocks on open
> > and then continues as soon as prog1 does the close().
> 
> No, prog wouldn't even have started until prog1 exited, so the behaviour 
> would be exactly the same.
> 
> And if the programs put themselves in the background, well, then the order 
> of them is totally undefined, so then prog2 might end up opening the sound 
> device _before_ prog1 even got to it. So I really don't see your point, 
> except as some very unlikely (and apparently totally broken) situation.
> 
> > btw, xmms is a sort-of relevant example of this. xmms opens and closes
> > the audio device several times during a typical use pattern
> 
> So? It will still end up doing exactly the same waiting. It just does it 
> at the close instead of at the open.
> 
> Maybe the timing is different, but does anybody really care?
> 
> If anything, I suspect that the "flush on close" should _not_ wait for the 
> sound to have stopped, because you may have applications that open and 
> close the thing, and you want the sound to be contiguous and you do _not_ 
> want to hear popping. 
> 
> So to avoid the popping issue, I'd suggest that the "flush on close"  
> doesn't actually wait for the sound to end, but it might wait until the
> final sound fragment has been sent to the device. So hopefully the next 
> app has a few milliseconds of time to re-open the stream and start filling 
> the buffers again, so that you don't get any popping.

If the end of the sound being played has an envelope that gradually[*]
decreases to zero and the last sample of the last buffer is zero, the
soundcard should not pop when the stream is closed. Unless there are
hardware issues impossible to solve through software I'd call that a
bug. 

If the samples being played end abruptly (ie: the last sample of the
last buffer to be played is non-zero) then there will be a pop
independently of whether we chain apps or not. It is highly unlikely
that the next app will start playing a sound that happens to have the
same starting DC level as the previous one ended with. Jump in DC level
== pop. 

-- Fernando

[*] I don't have a strict definition of what "gradually" would be, my
guesstimate would be minimum of between 5 and 10 milliseconds. 




-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click

Re: The ALSA Situation

[Jaroslav Kysela]

On Wed, 10 Nov 2004, Linus Torvalds wrote:

> So to avoid the popping issue, I'd suggest that the "flush on close"  
> doesn't actually wait for the sound to end, but it might wait until the
> final sound fragment has been sent to the device. So hopefully the next 
> app has a few milliseconds of time to re-open the stream and start filling 
> the buffers again, so that you don't get any popping.

Unfortunately, the application will have to settle other real-time
parameters (including stream parameters, i/o chunk sizes etc.), so we must
drain on close() the complete stream and not allow intermixing requests
from applications. I see the possibility to move the blocking from open()
to the parameter handshage stage (ioctl). In this case, new application
will block until new parameters can be applied. It can be serialized as
well.

But, in my eyes, this change is quite same from the application view, 
because the blocking will be only moved to another syscall. It will solve 
nothing from the original request - the application will block one another 
and the original user will see really same result.

The question is: What's worse?

1) delay applications (might cause problems with not-intelligent apps)
2) return -EBUSY error at open()

My final words:

For OSS API - I will turn the nonblock_open on by default.
For ALSA API - I will leave the blocking behaviour in open()
- the Posix has a definition space for STREAMS drivers - interpretation
of the O_NONBLOCK flag is upon the driver requirements, and we
documented this feature from the initial design phase.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs


-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click

Re: The ALSA Situation

[Linus Torvalds]

On Thu, 11 Nov 2004, Jaroslav Kysela wrote:
> 
> Unfortunately, the application will have to settle other real-time
> parameters (including stream parameters, i/o chunk sizes etc.), so we must
> drain on close() the complete stream and not allow intermixing requests
> from applications.

That seems to be a misdesign of the interfaces, but whatever. Make it 
return -EBUSY then.

		Linus


-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click

Re: The ALSA Situation

[Takashi Iwai]

At Wed, 10 Nov 2004 22:42:20 -0800 (PST),
Linus Torvalds wrote:
> 
> On Thu, 11 Nov 2004, Jaroslav Kysela wrote:
> > 
> > Unfortunately, the application will have to settle other real-time
> > parameters (including stream parameters, i/o chunk sizes etc.), so we must
> > drain on close() the complete stream and not allow intermixing requests
> > from applications.
> 
> That seems to be a misdesign of the interfaces, but whatever.

Well, the contiguous use of a stream isn't easy as it sounds.
Since each app wants different buffer size, period (fragment) size,
sample format, sample rate etc, the configuration must be reset
totally at each time.  This eventually requires to stop of the DMA.

It's possible to check the condition and contine if it's identical
with the previous one, though.  But I feel it's overdesigned as the
driver.  A practical way to avoid popping would be the damping as
Fernando suggested (if h/w doesn't support soft-muting).


Takashi


-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click

Re: The ALSA Situation

[Linus Torvalds]

On Thu, 11 Nov 2004, Takashi Iwai wrote:
> 
> Well, the contiguous use of a stream isn't easy as it sounds.
> Since each app wants different buffer size, period (fragment) size,
> sample format, sample rate etc, the configuration must be reset
> totally at each time.  This eventually requires to stop of the DMA.

... and the sane thing to do would be to let apps use default parameters, 
and _encourage_ that, so that they only have problems if they want to do 
something strange.

> It's possible to check the condition and contine if it's identical
> with the previous one, though.  But I feel it's overdesigned as the
> driver.  A practical way to avoid popping would be the damping as
> Fernando suggested (if h/w doesn't support soft-muting).

The popping is just a small thing. The bigger thing is that people want to 
have a sound device open and send occasional beeps to it and things. 
Without having to wait for everybody else to close their stream.

If a window manager can't send a beep because the user is listening to 
music, that's a bad thing. If the interfaces are designed so that the 
trivial case is hard, that's a bad thing. And it sounds like they are.

		Linus


-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click

Re: The ALSA Situation

[Takashi Iwai]

At Thu, 11 Nov 2004 08:58:28 -0800 (PST),
Linus Torvalds wrote:
> 
> On Thu, 11 Nov 2004, Takashi Iwai wrote:
> > 
> > Well, the contiguous use of a stream isn't easy as it sounds.
> > Since each app wants different buffer size, period (fragment) size,
> > sample format, sample rate etc, the configuration must be reset
> > totally at each time.  This eventually requires to stop of the DMA.
> 
> ... and the sane thing to do would be to let apps use default parameters, 
> and _encourage_ that, so that they only have problems if they want to do 
> something strange.

Oh, that's hard to tell what should be the "default" parameters.
This strongly depends on the board.

Then, the arising question is somewhat philosophical - should we
provide more functions or less functions the chip supports?

ALSA tries to provide as much function as possible.  This results in
variety of configurations, i.e. the famous complexity.
If we provide the limited functions, the API would be much easier just
like OSS.


> > It's possible to check the condition and contine if it's identical
> > with the previous one, though.  But I feel it's overdesigned as the
> > driver.  A practical way to avoid popping would be the damping as
> > Fernando suggested (if h/w doesn't support soft-muting).
> 
> The popping is just a small thing. The bigger thing is that people want to 
> have a sound device open and send occasional beeps to it and things. 
> Without having to wait for everybody else to close their stream.
> 
> If a window manager can't send a beep because the user is listening to 
> music, that's a bad thing. If the interfaces are designed so that the 
> trivial case is hard, that's a bad thing. And it sounds like they are.

The cocurrent access like beep can be solved by using a certain middle
layer instead of accessing the sound device directly.  For example,
most of desktop systems use a sound server like arts and esd.  Or, if
all the app run using ALSA API, they can live with the ALSA softmixing
in a peaceful world.

However, when different sound systems run at the same time, the world
peace is broken.  Each tries to grab the device exclusively.

I really wish that all these stuff will be based on a common library
which absorbs the difference of APIs.  Also, the use of the middle
layer library reduces the difficulty of the audio programming.


Takashi


-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click

Re: The ALSA Situation

[Linus Torvalds]

On Thu, 11 Nov 2004, Takashi Iwai wrote:
> 
> Oh, that's hard to tell what should be the "default" parameters.
> This strongly depends on the board.

Which is exactly why apps should not even try to set them.

My point is that the driver can select some default parameters, and then 
users just use them by default, and thus there are no issues of 
synchronizing between them.

> ALSA tries to provide as much function as possible.  This results in
> variety of configurations, i.e. the famous complexity.

That may or may not be a valid excuse.

Complexity also often arises from bad decisions. And the decision to only 
have one user open at a time appears like a pretty fundamentally bad one.

		Linus


-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click

Re: The ALSA Situation

[Manuel Jander]

Hi

On Thu, 2004-11-11 at 10:23 -0800, Linus Torvalds wrote:
> 
> On Thu, 11 Nov 2004, Takashi Iwai wrote:
> > 
> > Oh, that's hard to tell what should be the "default" parameters.
> > This strongly depends on the board.
> 
> Which is exactly why apps should not even try to set them.

At last somebody agree :) Frankly IMHO, setting buffer sizes in a sound
application, seemed always pretty silly thing to me. Its too much
hardware dependant, to be done inside a user application; sort of out of
scope.

> My point is that the driver can select some default parameters, and then 
> users just use them by default, and thus there are no issues of 
> synchronizing between them.

Yes, that would be very, very nice. At most, user program should have
the ability to ask for less_latency or longer_buffering, because that
relationship obviously is a tradeoff between 2 goodnesses. But most
current "options" don't actually provide any benefit. If choosen wrong,
sound output may even not work correctly.
The less options -> the more likelyhood that it will work (just works
paradigm).

> > ALSA tries to provide as much function as possible.  This results in
> > variety of configurations, i.e. the famous complexity.
> 
> That may or may not be a valid excuse.
> 
> Complexity also often arises from bad decisions. And the decision to only 
> have one user open at a time appears like a pretty fundamentally bad one.

I agree too. Its even worst with fear to a rewrite/redesign.

-- 
Manuel Jander
Electronic Engineer



-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click

Re: The ALSA Situation

[Manuel Jander]

Hi,

On Thu, 2004-11-11 at 17:34 +0100, Takashi Iwai wrote:
> At Wed, 10 Nov 2004 22:42:20 -0800 (PST),
> Linus Torvalds wrote:
> > 
> > On Thu, 11 Nov 2004, Jaroslav Kysela wrote:
> > > 
> > > Unfortunately, the application will have to settle other real-time
> > > parameters (including stream parameters, i/o chunk sizes etc.), so we must
> > > drain on close() the complete stream and not allow intermixing requests
> > > from applications.
> > 
> > That seems to be a misdesign of the interfaces, but whatever.
> 
> Well, the contiguous use of a stream isn't easy as it sounds.
> Since each app wants different buffer size, period (fragment) size,
> sample format, sample rate etc, the configuration must be reset
> totally at each time.  This eventually requires to stop of the DMA.

There 2 situations (AFAIK): 

1) * Stinking intel8x0 or similar card with only one stereo stream:
  - Device should be accessed as 48KHz 16 bit stereo (highest quality
available), since it most probably does not even have a samplerate
converter. There should be no concern about latency/buffer size, thats
just silly in such a kind of device. Just use the most efficient DMA
setup.
  - All applications using the device should be softmixed. It does not
make any sense to give direct access to applications.

2) * Multichannel card:
  - Use one channel for softmixing (reserved for ever for that purpose,
at highest audio quality). Just the same as for the single channel card.
  - Use a "Resource Manager" that assigns hardware channels as are
available, and choose the softmixing engine coupled to the reserved
channel when we get out of hardware channels.
   - If we want to make this even nicer, and thinking in the future
where hardware channels may have (they actually have, but are not
supported) advanced processing features, the "Resource Manager" could
assign hardware channels on behalf of the features the applications asks
for. For example if a application does not ask for HRTF processing, give
it a softmixing channel, or  a hardware channel lacking that feature.

As you can see, both situations are in essence the same, as if there is
only one hardware channel, after reserving the softmixing channel, you
got out of hardware channels, falling into the same situation as of a
multichannel device with all hardware channels being used.

That is my dream of a sound API behaviour. In 1996 they called that
A3D... so this ideas aren't quite new :P

Best Regards

-- 
Manuel Jander
Electronic Engineer



-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click

Re: The ALSA Situation

[Takashi Iwai]

At Thu, 11 Nov 2004 10:23:44 -0800 (PST),
Linus Torvalds wrote:
> 
> On Thu, 11 Nov 2004, Takashi Iwai wrote:
> > 
> > Oh, that's hard to tell what should be the "default" parameters.
> > This strongly depends on the board.
> 
> Which is exactly why apps should not even try to set them.
> 
> My point is that the driver can select some default parameters, and then 
> users just use them by default, and thus there are no issues of 
> synchronizing between them.

The parameters a board supports are not unique.  For example, suppose
a card supporting 8bit and 16bit samples.  An app using 8bit format
ran once, then you want to play an mp3 after that.  Should the driver
keep the last 8bit format?  Or, the driver shouldn't have accepted
8bit (thus convert it in software - i.e. no mmap) even though it's
natively supported?

So, the minimal setting such as the sample format, rate, channels, etc
are still required to be set by applications although I agree that the
configuration of buffer/period sizes can be more simplified.


> > ALSA tries to provide as much function as possible.  This results in
> > variety of configurations, i.e. the famous complexity.
> 
> That may or may not be a valid excuse.

Agreed :)

> Complexity also often arises from bad decisions. And the decision to only 
> have one user open at a time appears like a pretty fundamentally bad one.

If you mean the blocking behavior, I agree.  I myself don't like it,
too.
But, solving the concurrent access in another way in the *driver
level* (the intermediate buffer or the soft-mixing) doesn't sound good
to me.  It brings more complexity than the simple -EBUSY strategy.


Takashi


-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click

Re: The ALSA Situation

[Takashi Iwai]

At Thu, 11 Nov 2004 19:34:46 -0300,
Manuel Jander wrote:
> 
> Hi
> 
> On Thu, 2004-11-11 at 10:23 -0800, Linus Torvalds wrote:
> > 
> > On Thu, 11 Nov 2004, Takashi Iwai wrote:
> > > 
> > > Oh, that's hard to tell what should be the "default" parameters.
> > > This strongly depends on the board.
> > 
> > Which is exactly why apps should not even try to set them.
> 
> At last somebody agree :) Frankly IMHO, setting buffer sizes in a sound
> application, seemed always pretty silly thing to me. Its too much
> hardware dependant, to be done inside a user application; sort of out of
> scope.

Hmm, the minimal setting ALSA API requires is not so much: the sample
format, rate, channels, access mode, buffer/period sizes.
I believe these except buffer/period sizes are almost mandatory in
every (native) audio API.  (Of course, the system like JACK is another
story. It converts everything by itself.)

> > My point is that the driver can select some default parameters, and then 
> > users just use them by default, and thus there are no issues of 
> > synchronizing between them.
> 
> Yes, that would be very, very nice. At most, user program should have
> the ability to ask for less_latency or longer_buffering, because that
> relationship obviously is a tradeoff between 2 goodnesses. But most
> current "options" don't actually provide any benefit. If choosen wrong,
> sound output may even not work correctly.
> The less options -> the more likelyhood that it will work (just works
> paradigm).

Here agreed.  The buffer configuration can be more simplified.
Having default values for the templates ("minimal latency" or "robust
playback") would be nice.


Takashi


-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click

Re: The ALSA Situation

[Giuliano Pochini]

On 11-Nov-2004 Linus Torvalds wrote:

>> Oh, that's hard to tell what should be the "default" parameters.
>> This strongly depends on the board.
>
> Which is exactly why apps should not even try to set them.

Yes, as far as all involved apps ask for the save "basic"
parameters: sample rate and number of channels.


>> ALSA tries to provide as much function as possible.  This results in
>> variety of configurations, i.e. the famous complexity.
>
> That may or may not be a valid excuse.
>
> Complexity also often arises from bad decisions. And the decision to only
> have one user open at a time appears like a pretty fundamentally bad one.

Well, perhaps I'm missing the point, but I don't see why
applications should be able to use the same hw stream at
the same time if the hw doesn't support mixing. The
result would not be what the user expects.

IMHO alsa should use dmix by default, unless the
application explicitly asks for bypassing it.


--
Giuliano.


-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click

Re: The ALSA Situation

[Takashi Iwai]

At Thu, 11 Nov 2004 19:52:47 -0300,
Manuel Jander wrote:
> 
> Hi,
> 
> On Thu, 2004-11-11 at 17:34 +0100, Takashi Iwai wrote:
> > At Wed, 10 Nov 2004 22:42:20 -0800 (PST),
> > Linus Torvalds wrote:
> > > 
> > > On Thu, 11 Nov 2004, Jaroslav Kysela wrote:
> > > > 
> > > > Unfortunately, the application will have to settle other real-time
> > > > parameters (including stream parameters, i/o chunk sizes etc.), so we must
> > > > drain on close() the complete stream and not allow intermixing requests
> > > > from applications.
> > > 
> > > That seems to be a misdesign of the interfaces, but whatever.
> > 
> > Well, the contiguous use of a stream isn't easy as it sounds.
> > Since each app wants different buffer size, period (fragment) size,
> > sample format, sample rate etc, the configuration must be reset
> > totally at each time.  This eventually requires to stop of the DMA.
> 
> There 2 situations (AFAIK): 
> 
> 1) * Stinking intel8x0 or similar card with only one stereo stream:
>   - Device should be accessed as 48KHz 16 bit stereo (highest quality
> available), since it most probably does not even have a samplerate
> converter.

No, most of boards have SRC (on AC97 chip).  The board without SRC is
rare nowadays.

>  There should be no concern about latency/buffer size, thats
> just silly in such a kind of device. Just use the most efficient DMA
> setup.
>   - All applications using the device should be softmixed. It does not
> make any sense to give direct access to applications.

IMO, it's too narrow-sighted.  You can't say that no user wants the
low-latency system like JACK for an onboard chip.  There definitely
are (imagine laptop users).

But for _normal_ apps, yes, they should all use the softmix.

> 2) * Multichannel card:
>   - Use one channel for softmixing (reserved for ever for that purpose,
> at highest audio quality). Just the same as for the single channel card.
>   - Use a "Resource Manager" that assigns hardware channels as are
> available, and choose the softmixing engine coupled to the reserved
> channel when we get out of hardware channels.
>    - If we want to make this even nicer, and thinking in the future
> where hardware channels may have (they actually have, but are not
> supported) advanced processing features, the "Resource Manager" could
> assign hardware channels on behalf of the features the applications asks
> for. For example if a application does not ask for HRTF processing, give
> it a softmixing channel, or  a hardware channel lacking that feature.

The multichannel cards have usually no hardware mixing.  They provide
one DMA for all channels, either interleaved or non-interleaved.

So, decoupling these channels means that one has to grab all channels
exclusively and distribute them.  The situation is pretty similar like
the first case, anyway.


Takashi


-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click

Re: The ALSA Situation

[Linus Torvalds]

On Fri, 12 Nov 2004, Takashi Iwai wrote:
>
> But, solving the concurrent access in another way in the *driver
> level* (the intermediate buffer or the soft-mixing) doesn't sound good
> to me.  It brings more complexity than the simple -EBUSY strategy.

I won't argue against that. I don't actually mind EBUSY myself. At least
it's a pretty obvious error condition, and together with some (alternate)  
mixing interface - whether user or kernel mode - I don't think there is
anything fundamentally wrong with just saying "I'm busy, I can't take you
right now".

My arguments have really been against blocking. And to some degree an 
argument against people thinking it's _good_ to set individual parameters. 

		Linus


-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click

Re: The ALSA Situation

[Florian Schmidt]

On Fri, 12 Nov 2004 07:50:58 -0800 (PST)
Linus Torvalds <torvalds@osdl.org> wrote:

> I won't argue against that. I don't actually mind EBUSY myself. At least
> it's a pretty obvious error condition, and together with some (alternate)  
> mixing interface - whether user or kernel mode - I don't think there is
> anything fundamentally wrong with just saying "I'm busy, I can't take you
> right now".

Hi,

for whatever it's worth i completely agree with just using EBUSY when the
device is not available for a program (no additional open allowed by the
hw). This blocking behaviour is the single most irritating aspect of ALSA.

> 
> My arguments have really been against blocking. And to some degree an 
> argument against people thinking it's _good_ to set individual parameters. 

Historically seen there's a long tradition for sound applications to choose
their own parameters as different applications serve vastly different
purposes and thus imply different paramaters to be used.

A low latency realtime effects box program will need completely different
periodsize and periodcount settings than a program without realtime needs
like a highly reliable harddisc recorder. The former will use a very small
periodsize and a periodcount of 2 (or the minimum available by the hw), the
latter will use the opposite (large periodsizes and a high periodcount).

The need for software mixing is somewhat orthogonal to this, as it enforces
a particular set of settings on all programs using this software mixing
device. The software mixing device might still allow the programs to use
their own set of parameters, but this would require some sort of
conversion/translation (and of course a program, using a periodsize/count
smaller than the ones the software mixing device uses to communicate with
the hw, doesn't gain anything by doing so).

For compatibility issues this translation/conversion is a must and since
ALSA aims to provide full compatibility for OSS apps, the software mixing
and conversion must be available to the OSS emulation layer as well.

The current "ALSA situation" looks like follows (correct me people if i talk
BS):

1. ALSA infrastructure kernel modules (pcm, seq, ctl, other voodoo stuff)
2. ALSA driver modules (using 1.)
3. ALSA OSS emulation modules (using 2. used directly by OSS apps)
4. ALSA-lib (using 2. used by ALSA apps)
5. ALSA-oss-lib (using 4. LD_PRELOAD hack to make OSS apps use ALSA-lib)

ALSA does provide software mixing and conversion routines. But these reside
in ALSA-lib, thus to make use of them systemwide, both ALSA apps and OSS
apps need to go through ALSA-lib. This is a natural thing for ALSA apps as
it was designed this way. For OSS apps one needs to use the ALSA-oss-lib
(5]), which is a hack and doesn't work with all OSS apps, as there is no way
to LD_PRELOAD symbols which are not resolved at runtime (excuse my possibly
wrong terminology).

IMHO it would be better to have the software mixing and conversion code in a
place where the ALSA OSS emulation modules can make use of them. I don't
know how feasible it is to call userspace stuff from the kernel space, but i
can imagine it's rather difficult. Thus the software mixing and conversion
stuff should live in the kernel.

I'm not arguing against having plugin functionality in ALSA-lib per se.
There's many uses for this (effects, routing between alsa apps), but i think
the fundamental mixing/conversion stuff is really needed in the kernel.

So how to add this functionality to ALSA with the least effort and breakage?
Personally i think the following is the best approach:

1. ALSA infrastructure kernel modules (pcm, seq, ctl, other voodoo stuff) 
2. ALSA driver modules (using 1. one instance for every real soundcard driver) 
3. ALSA virtual soundcard modules (using 2. sw mixing plus conversion for 2.) 
4. ALSA OSS emulation modules (using 2 or 3. used directly by OSS apps) 
5. ALSA-lib (using 2 or 3. used by ALSA apps) 

The ALSA virtual soundcard module (3.) would look to ALSA-lib or to the ALSA
OSS emulation modules just like a normal soundcard. When used it "opens" the
underlying ALSA driver module and provides software mixing and conversion by
allowing umlimited open's and arbitrary parameters to all applications using
it either through the OSS emulation modules or ALSA-lib.

Actually thanks to the design of ALSA, this is really all that needs to be
done to provide software mixing to all OSS apps and to all ALSA apps. The
distribution/user would only have to make sure that the virtual soundcard
module is loaded for the card and that both OSS emu modules and ALSA-lib use
it as default. For professional users neeeddng direct access to the hardware
they still have the option of using the real ALSA driver (as long as it's not
in use by the virtual soundcard module of course).

Sadly i have no idea about how difficult it would be to code up such a
virtual soundcard module, but i suppose some of the
resampling/mixing/conversion code in ALSA-lib can be reused. I have never
attempted to program a module, so i leave judgement about this idea to the
gurus :)

What other ways to intergrate this into the ALSA structure are there? And
how much effort do they take? In the end it all comes down to developer
time. I own a hardware mixing capable soundcard, so i can happily live with
the current ALSA state, but IMHO this is a very important thing missing for
the completely positive ALSA experience. ALSA has improved the situation for
a serious linux musician/audio user tremendously over OSS (which was really
a crutch). The final missing building block is providing an equally positive
experience to the laptop user with his crappy soundcard needing bleeps and
music at the same time..

(putting on flame suit, have at it ;))

   Florian Schmidt


-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8

Re: The ALSA Situation

[Manuel Jander]

Hi,

On Fri, 2004-11-12 at 23:06 +0100, Florian Schmidt wrote:
> On Fri, 12 Nov 2004 07:50:58 -0800 (PST) 
> > My arguments have really been against blocking. And to some degree an 
> > argument against people thinking it's _good_ to set individual parameters. 
> 
> Historically seen there's a long tradition for sound applications to choose
> their own parameters as different applications serve vastly different
> purposes and thus imply different paramaters to be used.

Nowadays, with so many different hardware around (USB, PCI, ISA,
firewire, etc), it may even happen that two soundcards have mutually
exclusive settings, in other words, you may not able to find a period
number and period size setting that will work on both. Forget about
trying some period setup that will work on every soundcard, even those
still not invented. That is absolutely  nonsense in my opinion. This bad
assumption should be put to an end as soon as possible, if not things
will (they actually are now) very messy, in regard of soundcard
parameter selection.

By now, the only solution i can think of, is doing some measurements at
startup, to determine the feasible period size/count bounds, without
xruns.

> A low latency realtime effects box program will need completely different
> periodsize and periodcount settings than a program without realtime needs
> like a highly reliable harddisc recorder. The former will use a very small
> periodsize and a periodcount of 2 (or the minimum available by the hw), the
> latter will use the opposite (large periodsizes and a high periodcount).

I agree. But again, this is highly hardware dependant, and some setting
may work splendid on your computer, but maybe wont on mine. Even using
the same soundcard, because even the system bus characteristics may
influence a lot.

> The need for software mixing is somewhat orthogonal to this, as it enforces
> a particular set of settings on all programs using this software mixing
> device. The software mixing device might still allow the programs to use
> their own set of parameters, but this would require some sort of
> conversion/translation (and of course a program, using a periodsize/count
> smaller than the ones the software mixing device uses to communicate with
> the hw, doesn't gain anything by doing so).

Application should not need to care about buffer setup. If they do, the
chance to fail is very high; in other words: flaky.
Sometimes things are not optimal, but its better to be sure that it will
work without xruns.

> For compatibility issues this translation/conversion is a must and since
> ALSA aims to provide full compatibility for OSS apps, the software mixing
> and conversion must be available to the OSS emulation layer as well.
> 
> The current "ALSA situation" looks like follows (correct me people if i talk
> BS):
> 
> 1. ALSA infrastructure kernel modules (pcm, seq, ctl, other voodoo stuff)
> 2. ALSA driver modules (using 1.)
> 3. ALSA OSS emulation modules (using 2. used directly by OSS apps)
> 4. ALSA-lib (using 2. used by ALSA apps)
> 5. ALSA-oss-lib (using 4. LD_PRELOAD hack to make OSS apps use ALSA-lib)
> 
> ALSA does provide software mixing and conversion routines. But these reside
> in ALSA-lib, thus to make use of them systemwide, both ALSA apps and OSS
> apps need to go through ALSA-lib. This is a natural thing for ALSA apps as
> it was designed this way. For OSS apps one needs to use the ALSA-oss-lib
> (5]), which is a hack and doesn't work with all OSS apps, as there is no way
> to LD_PRELOAD symbols which are not resolved at runtime (excuse my possibly
> wrong terminology).
> 
> IMHO it would be better to have the software mixing and conversion code in a
> place where the ALSA OSS emulation modules can make use of them. I don't
> know how feasible it is to call userspace stuff from the kernel space, but i
> can imagine it's rather difficult. Thus the software mixing and conversion
> stuff should live in the kernel.
> 
> I'm not arguing against having plugin functionality in ALSA-lib per se.
> There's many uses for this (effects, routing between alsa apps), but i think
> the fundamental mixing/conversion stuff is really needed in the kernel.
> 
> So how to add this functionality to ALSA with the least effort and breakage?
> Personally i think the following is the best approach:
> 
> 1. ALSA infrastructure kernel modules (pcm, seq, ctl, other voodoo stuff) 
> 2. ALSA driver modules (using 1. one instance for every real soundcard driver) 
> 3. ALSA virtual soundcard modules (using 2. sw mixing plus conversion for 2.) 
> 4. ALSA OSS emulation modules (using 2 or 3. used directly by OSS apps) 
> 5. ALSA-lib (using 2 or 3. used by ALSA apps) 
> 
> The ALSA virtual soundcard module (3.) would look to ALSA-lib or to the ALSA
> OSS emulation modules just like a normal soundcard. When used it "opens" the
> underlying ALSA driver module and provides software mixing and conversion by
> allowing umlimited open's and arbitrary parameters to all applications using
> it either through the OSS emulation modules or ALSA-lib.
> 
> Actually thanks to the design of ALSA, this is really all that needs to be
> done to provide software mixing to all OSS apps and to all ALSA apps. The
> distribution/user would only have to make sure that the virtual soundcard
> module is loaded for the card and that both OSS emu modules and ALSA-lib use
> it as default. For professional users neeeddng direct access to the hardware
> they still have the option of using the real ALSA driver (as long as it's not
> in use by the virtual soundcard module of course).
> 
> Sadly i have no idea about how difficult it would be to code up such a
> virtual soundcard module, but i suppose some of the
> resampling/mixing/conversion code in ALSA-lib can be reused. I have never
> attempted to program a module, so i leave judgement about this idea to the
> gurus :)
> 
> What other ways to intergrate this into the ALSA structure are there? And
> how much effort do they take? In the end it all comes down to developer
> time. I own a hardware mixing capable soundcard, so i can happily live with
> the current ALSA state, but IMHO this is a very important thing missing for
> the completely positive ALSA experience. ALSA has improved the situation for
> a serious linux musician/audio user tremendously over OSS (which was really
> a crutch). The final missing building block is providing an equally positive
> experience to the laptop user with his crappy soundcard needing bleeps and
> music at the same time..

Imagine, you have a virtual soundcard module, that mixes together all
the streams you want... How do you make use of it ? Who decides which
hardware stream is going to used ? Who decides if a application is
granted a hardware stream or takes part of the virtual device ? 

IMHO, ALSA requires a resource manager. And before someone starts
hacking any shit, please let us design something well done.


-- 
Manuel Jander
Electronic Engineer



-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8

Re: The ALSA Situation

[Jaroslav Kysela]

On Fri, 12 Nov 2004, Manuel Jander wrote:

> By now, the only solution i can think of, is doing some measurements at
> startup, to determine the feasible period size/count bounds, without
> xruns.

I would suggest to look to snd_spcm functions in alsa-lib/include/pcm.h.
The alsa-lib will take care.

I think that the bottom HAL should be kept as is (to allow every 
parameters for specific apps), but we can simplify the initialization
for standard set of applications.

> IMHO, ALSA requires a resource manager. And before someone starts
> hacking any shit, please let us design something well done.

Exactly. We need a configuration manager for alsa-lib.
We can discuss it right now.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs


-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8

Re: The ALSA Situation

[Jaroslav Kysela]

On Fri, 12 Nov 2004, Florian Schmidt wrote:

> Sadly i have no idea about how difficult it would be to code up such a
> virtual soundcard module, but i suppose some of the
> resampling/mixing/conversion code in ALSA-lib can be reused. I have never
> attempted to program a module, so i leave judgement about this idea to the
> gurus :)

I started coding of the loopback driver which simply makes this:

PCM loopback playback device -> PCM loopback capture device

With this module, we can do easy rerouting for OSS emulation from the 
kernel space back to the user space and do all necessary extended 
operation via alsa-lib before samples are sent to real sound hardware.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs


-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8

Re: The ALSA Situation

[Florian Schmidt]

On Sat, 13 Nov 2004 11:42:54 +0100 (CET)
Jaroslav Kysela <perex@suse.cz> wrote:

> I started coding of the loopback driver which simply makes this:
> 
> PCM loopback playback device -> PCM loopback capture device
> 
> With this module, we can do easy rerouting for OSS emulation from the 
> kernel space back to the user space and do all necessary extended 
> operation via alsa-lib before samples are sent to real sound hardware.

Cool, great news! :) How easy will it be for an end user to set this up? And
another question: will it support mmap'ed mode?

Flo


-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8

Re: The ALSA Situation

[Linus Torvalds]

On Sat, 13 Nov 2004, Florian Schmidt wrote:
> 
> Cool, great news! :) How easy will it be for an end user to set this up? And
> another question: will it support mmap'ed mode?

Perhaps more importantly - will it be usable.

Sound is latency-critical. It's one of the _last_ things you want to have 
do a roundtrip to user mode..

		Linus


-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8

Re: The ALSA Situation

[Manuel Jander]

Hi,

> > IMHO, ALSA requires a resource manager. And before someone starts
> > hacking any shit, please let us design something well done.
> 
> Exactly. We need a configuration manager for alsa-lib.
> We can discuss it right now.

Excelent ! Since a long time, i have been collecting ideas about
this... 

First of all, i would propose to make a detailed and complete
requirements definition.
For that purpose i'm soliciting write access to the ALSA Wiki, because i
think it would be appropriate for sharing ideas, and the requirement
documentation itself (our drawing board).

IMHO, this would be roughly the steps involved:
1) Definition of requirements.
2) Design.
3) Implementation.

As soon as i get write access to the ALSA wiki (if not, i'll setup my
own), i will post there my current ideas, in order to start.

Cheers,

-- 
Manuel Jander
Electronic Engineer



-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8

Configuration system and Resource Manager. Was: Re: The ALSA Situation

[Manuel Jander]

Hi,

> > IMHO, ALSA requires a resource manager. And before someone starts
> > hacking any shit, please let us design something well done.
> 
> Exactly. We need a configuration manager for alsa-lib.
> We can discuss it right now.
> 

Well, I started drawing some lines. For everyone interested, take a look and feel free to modify.
This preliminary.

http://alsa.opensrc.org/index.php?page=DrawingBoard


-- 
Manuel Jander
Electronic Engineer



-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8

Re: The ALSA Situation

[Florian Schmidt]

On Sat, 13 Nov 2004 11:42:54 +0100 (CET)
Jaroslav Kysela <perex@suse.cz> wrote:

> On Fri, 12 Nov 2004, Florian Schmidt wrote:
> 
> > Sadly i have no idea about how difficult it would be to code up such a
> > virtual soundcard module, but i suppose some of the
> > resampling/mixing/conversion code in ALSA-lib can be reused. I have never
> > attempted to program a module, so i leave judgement about this idea to the
> > gurus :)
> 
> I started coding of the loopback driver which simply makes this:
> 
> PCM loopback playback device -> PCM loopback capture device
> 
> With this module, we can do easy rerouting for OSS emulation from the 
> kernel space back to the user space and do all necessary extended 
> operation via alsa-lib before samples are sent to real sound hardware.

Hi, an irc user told me today that artsdsp seems to have an mmap
emulation that works for games like Enemy Territory (which uses mmap
with OSS). I haven't looked into the source yet, but maybe we can rip
some more :)

flo


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: The ALSA Situation

[Clemens Ladisch]

Andreas Mohr wrote:
> Don't we have a problem here??
> ...
> d) H/W (1/4) * S/W (1/4) each == S/W (1/16) each !!
>
> which clearly has a different volume (1/16 of total output) than each
> of the H/W-mix-only channels (1/4).

dmix simply adds (and clips), so this isn't a problem.


Clemens



-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click

Re: The ALSA Situation

[Manuel Jander]

Hi,

On Fri, 2004-11-12 at 09:24 +0100, Andreas Mohr wrote:
> Hi,
> > 2) * Multichannel card:
> >   - Use one channel for softmixing (reserved for ever for that purpose,
> > at highest audio quality). Just the same as for the single channel card.
> >   - Use a "Resource Manager" that assigns hardware channels as are
> > available, and choose the softmixing engine coupled to the reserved
> > channel when we get out of hardware channels.
> 
> Don't we have a problem here??
> 
> If we have 4 hardware-mixed channels and 7 sound streams, then we end
> up with:
> a) H/W (1/4)
> b) H/W (1/4)
> c) H/W (1/4)
> d) H/W (1/4): S/W (1/4), S/W (1/4), S/W (1/4), S/W (1/4)
> == (!!)
> d) H/W (1/4) * S/W (1/4) each == S/W (1/16) each !!
> 
> which clearly has a different volume (1/16 of total output) than each
> of the H/W-mix-only channels (1/4).
> 
> Hmm, OTOH there's a 150% likelihood that the card can adjust hardware
> channel volume individually, so just adjust channel d) to have 4 times
> the volume of each other H/W channel and you end up with equal volume.
> 
> OK, so that should be a non-issue after all (but we need to remember to
> adjust H/W channel volume each time the number of S/W channels changes!),

OK, there maybe some details, but that it absolutely irrelevant, because
it *can* be solved. The really import thing here IMHO is to solve the
concurrent access to the soundcard in a most useful manner, which is an
issue that is *not* solved yet.

-- 
Manuel Jander
Electronic Engineer



-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click

Re: The ALSA Situation

[Andreas Mohr]

Hi,

On Thu, Nov 11, 2004 at 08:05:24PM -0800, alsa-devel-request@lists.sourceforge.net wrote:
> Subject: Re: [Alsa-devel] The ALSA Situation
> From: Manuel Jander <manuel.jander@usm.cl>
> Reply-To: mjander@users.sourceforge.net
> To: Takashi Iwai <tiwai@suse.de>,
>    alsa-devel <alsa-devel@lists.sourceforge.net>
> Date: Thu, 11 Nov 2004 19:52:47 -0300

> 2) * Multichannel card:
>   - Use one channel for softmixing (reserved for ever for that purpose,
> at highest audio quality). Just the same as for the single channel card.
>   - Use a "Resource Manager" that assigns hardware channels as are
> available, and choose the softmixing engine coupled to the reserved
> channel when we get out of hardware channels.

Don't we have a problem here??

If we have 4 hardware-mixed channels and 7 sound streams, then we end
up with:
a) H/W (1/4)
b) H/W (1/4)
c) H/W (1/4)
d) H/W (1/4): S/W (1/4), S/W (1/4), S/W (1/4), S/W (1/4)
== (!!)
d) H/W (1/4) * S/W (1/4) each == S/W (1/16) each !!

which clearly has a different volume (1/16 of total output) than each
of the H/W-mix-only channels (1/4).

Hmm, OTOH there's a 150% likelihood that the card can adjust hardware
channel volume individually, so just adjust channel d) to have 4 times
the volume of each other H/W channel and you end up with equal volume.

OK, so that should be a non-issue after all (but we need to remember to
adjust H/W channel volume each time the number of S/W channels changes!),

Andreas Mohr


-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click

Re: The ALSA Situation

[Manuel Jander]

Hi,

[snip]
> In my azt3328 driver, I went through great pains to try to avoid popping
> (mostly successful), but I guess some of that work is actually not necessary
> any more once stream popping issues get handled at ALSA level.
> (BTW: does the other operating system take any measures against popping?)

Yes, some driver do, but as usual every driver does this kind of stuff
on their own.
Would be nice to see that in ALSA. Should not be that difficult, its
just about appending a few samples ramping toward zero when stopping the
device.

Manuel Jander

-- 
Manuel Jander
Electronic Engineer



-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click

Re: The ALSA Situation

[Andreas Mohr]

Hi,

On Wed, Nov 10, 2004 at 03:54:01PM -0800, alsa-devel-request@lists.sourceforge.net wrote:
> Message: 9
> Subject: Re: [Alsa-devel] The ALSA Situation
> From: Fernando Pablo Lopez-Lezcano <nando@ccrma.Stanford.EDU>
> To: Linus Torvalds <torvalds@osdl.org>
> Cc: Paul Davis <paul@linuxaudiosystems.com>, Jaroslav Kysela <perex@suse.cz>,
>         alsa-devel@lists.sourceforge.net
> Organization: 
> Date: 10 Nov 2004 15:53:08 -0800
> 
> If the end of the sound being played has an envelope that gradually[*]
> decreases to zero and the last sample of the last buffer is zero, the
> soundcard should not pop when the stream is closed. Unless there are
> hardware issues impossible to solve through software I'd call that a
> bug. 
> 
> If the samples being played end abruptly (ie: the last sample of the
> last buffer to be played is non-zero) then there will be a pop
> independently of whether we chain apps or not. It is highly unlikely
> that the next app will start playing a sound that happens to have the
> same starting DC level as the previous one ended with. Jump in DC level
> == pop. 

Which is why this popping would probably be best solved at ALSA internal
level (not driver level, either; the driver should just make sure that
its soundcard handling doesn't interfere with ALSAs intentions).
I.e. when opening/closing a stream, make sure it fades in/out without
strongly disturbing the currently played (or not played in case of
silence level) state.
And allow this "smoothing" to be turned off for high-end audio users,
of course...

In my azt3328 driver, I went through great pains to try to avoid popping
(mostly successful), but I guess some of that work is actually not necessary
any more once stream popping issues get handled at ALSA level.
(BTW: does the other operating system take any measures against popping?)

Andreas Mohr


-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click