[linux-audio-user] Common linux audio layer

[Christoph Eckert]

> At the risk of recomplicating the issue, I guess some
> complication is a result of the Linux multiuser and
> networking capabilities.

Lets think in long terms. So, your ideas are very good.

> I haven't used Windows beyond Win95, maybe someone can
> answer how Windows in the multiuser implementations handles
> these three situations (are there more):

Hmmmmm, I do not like the comparison to windows; let's have 
our own ideas :) .

>    * If there is more than one user on a machine (each with
> his own "terminal" (i.e., keyboard, CRT, mouse and *sound
> card and speakers*), and one of those users starts an audio
> application, what does Windows do?  (Presumably, the right
> thing is that Windows notes which user requests the
> application and routes the sound to his sound
> card/speakers.)

I presume that there is a jack server running on both 
machines, the client and the server. We could have a 
jackified audio streaming application which sends the audio 
data over the LAN to the client machine. There'll have a 
jackified streamin audio client which plays the audio through 
the speakers of the client machine.

>    * If there is more than one user on a machine (each with
> his own "partial terminal" (i.e., keyboard, CRT, mouse, but
> they *share a common sound card and speakers*), and one of
> those users starts an audio application, what does Windows
> do?  (I'm not sure of the right thing here, my guess is
> that the default would be to route the output to a mixer
> driving the common audio card, with easily accessible
> options to do things like mute the existing sound output,
> or mute the new application's output, or ???)

I presume that there is a jack server running on this machine 
which has been started at boot time in root mode (yes, that's 
a big security issue, but lets think in long terms).

Each of the users is allowed to connect to the jack root 
server (perhaps there's a system to exclude some users from 
write access to JACK, maybe by some groups).

Each user can tell its jackified applications to output sound 
or not.

Perhaps all users can have access to the hardware mixer, but 
this is not necessary (except someone has risen the mixer to 
the maximum output before ;-).

>    * If there is more than one user on a machine (but the
> user in question is logging in remotely (as via Telnet,
> ssh, remote X, or similar), and one of those remotely
> logged in users starts an audio application, what does
> Windows do?  (I'm guessing that the right thing is to route
> the audio output back to the remote user (somehow) and not
> interfere with the audio output of the "local" computer,
> again with options to route the output to the sound card of
> the local computer.)

See point one. A specialized jackified client can stream the 
audio to the destination machine, and perhaps it is clever 
enough to reduce the audio quality if the connection is slow.

> Of course ( ;-) ) for the simplest case, (a single user on
> a single user machine), the sound application should be
> default simply route the sound to the (single) (local)
> sound card, mixing the output with that of any other audio
> applications, with options to mute either the output of the
> old sound application(s) or the new sound application.

Again, I presume that there is a jack server running on this 
machine which has been started at boot time in root mode.

Or, if you like it more, JACK gets started as soon as a single 
user logs in, so JACK doesn't need to run in root mode.

But one problem remains: what if we have more than one 
soundcard? JACK cannot handle two cards at the same time due 
to timing issues.

Shall we start two instances of jack? Why not?

And BTW: the AC97 successor, high definition audio HDA, is 
prepared so the operating system can make certain 
applications remember and automatically reconnect to a 
certain output. This way, a user can play ogg files through 
external speakers, while an incoming SIP call rings through 
the same speakers but does output the speech automatically 
through the headset and not through the speakers.

> I guess part of my point is that the "proper" behavior
> needs to be agreed upon for each of these cases (and
> others?), before a complete resolution can be developed.

Well, I enjoy it to spend some thoughts to such cases.

> PS: Aside: Until recently, I was a lurker on some of the
> Xfree86 and (what's the new one, X.org?) mail lists, and
> one or both of these organizations were considering somehow
> dealing with audio issues similar to the above.  I have no
> idea how far along they are with such efforts (or whether
> they've since decided to drop the issues.)

Well, in the X treminology, a display is a set of a keyboard, 
a mouse and a screen. From their point of view, it would be 
right to include audio output into the definition of the 
meaning of 'display'.


 Best regards


    ce