Hi all,
I'm having some apps running on my desktop that all want
exclusive access to my sound device just for playing audio
(and a single app for capturing), namely:
* TeamSpeak (VoIP team voice chat)
* Cedega (for playing some win32 games on my beloved box)
* KDE/arts (my desktop wants to play some sounds as well wtf)
While I could easily disable my desktop sounds, and yeah, forget about the
music, but I'd still like to be in TeamSpeak (talking to friends and alike)
while playing a game using cedega.
Unfortunately, *all* those stupid (2) apps want exclusive access to the OSS
layout of my ALSA drivers, though, there just came into my mind to buy a
second audio device and wear a second headset (a little one below/under my
big one). But I couldn't find it handy anyway :(
So, in the end, what about writing a virtual OSS driver that can spawn
multiple (fake) /dev/vdsp%d's that all allow audio rendering (output) and at
least a single one capturing (this at least would fit *my* needs).
This virtual driver then would has to know about the real audio device then of
course that would it use to merge/mix the audio outputs to and to read the
requested capture data from.
Okay, neat idea, but I never ever wrote a single kernel code line!
So, can some guys of you please help me out there in *either* telling me where
to find the basics on kernel module writing *and* how to do such things like
I said I want.
Or, even if you feel that happy about that idea and can't wait until I got
stuck in finishing it, and you can DIYS, that would be even much nicer.
C/C++ is not my problem, and I have already seen/read the linux kernel code
not just once, but I am definitely laggin in experience in kernel
development.
Please help.
Thanks in advance,
Christian Parpart.
Hi Christian,
On 11/21/05, Christian Parpart < [email protected]> wrote:
> Hi all,
> I'm having some apps running on my desktop that all want
> exclusive access to my sound device just for playing audio
> (and a single app for capturing), namely:
>
> * TeamSpeak (VoIP team voice chat)
> * Cedega (for playing some win32 games on my beloved box)
> * KDE/arts (my desktop wants to play some sounds as well wtf)
Slack 10 with 2.6.14.2 using ALSA (artsd).
I have never had any problems with TS and other apps accessing sound* - KDE
notifications happen when I am on TS and playing a game of Quake2 while
listening to xmms on my patented mp3's.
What distro? What kernel? What desktop manager you use?
Nick
* I still can't get firefox and flash sound to work though - all OK in konq.
--
http://sourceforge.net/projects/quake2plus/
"Person who say it cannot be done should not interrupt person doing it."
-Chinese Proverb
On Mon, 2005-11-21 at 22:16 +0100, Christian Parpart wrote:
> Hi all,
>
> I'm having some apps running on my desktop that all want
> exclusive access to my sound device just for playing audio
> (and a single app for capturing), namely:
>
> * TeamSpeak (VoIP team voice chat)
> * Cedega (for playing some win32 games on my beloved box)
> * KDE/arts (my desktop wants to play some sounds as well wtf)
>
> While I could easily disable my desktop sounds, and yeah, forget about the
> music, but I'd still like to be in TeamSpeak (talking to friends and alike)
> while playing a game using cedega.
>
> Unfortunately, *all* those stupid (2) apps want exclusive access to the OSS
> layout of my ALSA drivers, though, there just came into my mind to buy a
> second audio device and wear a second headset (a little one below/under my
> big one). But I couldn't find it handy anyway :(
This problem is (mostly) solved already. You have to use aoss (alsa-lib
based OSS emulation) on top of dmix (software mixing for soundcards too
lame to do it in hardware). With a recent ALSA dmix is already used by
default so the only change needed is to launch the OSS apps with the
aoss wrapper e.g. aoss ./foo-oss-app. Since it's not completely
transparent this problem will have to be solved at the distro level, by
making sure all OSS apps are run with this wrapper.
This method should only be needed for closed source apps, an open source
app like artsd should be ported to use the ALSA API.
Lee
On Mon, 2005-11-21 at 21:39 +0000, Nick Warne wrote:
> Slack 10 with 2.6.14.2 using ALSA (artsd).
>
> I have never had any problems with TS and other apps accessing sound*
> - KDE notifications happen when I am on TS and playing a game of
> Quake2 while listening to xmms on my patented mp3's.
>
You probably use an emu10k1 or other hardware mixing soundcard.
Lee
On Monday 21 November 2005 21:40, Lee Revell wrote:
> On Mon, 2005-11-21 at 22:16 +0100, Christian Parpart wrote:
> > Hi all,
> >
> > I'm having some apps running on my desktop that all want
> > exclusive access to my sound device just for playing audio
> > (and a single app for capturing), namely:
> >
> > * TeamSpeak (VoIP team voice chat)
> > * Cedega (for playing some win32 games on my beloved box)
> > * KDE/arts (my desktop wants to play some sounds as well wtf)
> >
> > While I could easily disable my desktop sounds, and yeah, forget about
> > the music, but I'd still like to be in TeamSpeak (talking to friends and
> > alike) while playing a game using cedega.
> >
> > Unfortunately, *all* those stupid (2) apps want exclusive access to the
> > OSS layout of my ALSA drivers, though, there just came into my mind to
> > buy a second audio device and wear a second headset (a little one
> > below/under my big one). But I couldn't find it handy anyway :(
>
> This problem is (mostly) solved already. You have to use aoss (alsa-lib
> based OSS emulation) on top of dmix (software mixing for soundcards too
> lame to do it in hardware). With a recent ALSA dmix is already used by
> default so the only change needed is to launch the OSS apps with the
> aoss wrapper e.g. aoss ./foo-oss-app. Since it's not completely
> transparent this problem will have to be solved at the distro level, by
> making sure all OSS apps are run with this wrapper.
>
> This method should only be needed for closed source apps, an open source
> app like artsd should be ported to use the ALSA API.
Which it already has been, for literally years.
[alistair] 02:26 [~] artsd -A
possible choices for the audio i/o method:
toss Threaded Open Sound System
null No Audio Input/Output
alsa Advanced Linux Sound Architecture
oss Open Sound System
--
Cheers,
Alistair.
'No sense being pessimistic, it probably wouldn't work anyway.'
Third year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
On Tue, 2005-11-22 at 02:26 +0000, Alistair John Strachan wrote:
> Which it already has been, for literally years.
>
> [alistair] 02:26 [~] artsd -A
> possible choices for the audio i/o method:
>
> toss Threaded Open Sound System
> null No Audio Input/Output
> alsa Advanced Linux Sound Architecture
> oss Open Sound System
>
Unfortunately it still seems to default to OSS on many systems.
Lee
On Mon, 21 Nov 2005, Lee Revell wrote:
> On Mon, 2005-11-21 at 22:16 +0100, Christian Parpart wrote:
> > Hi all,
> >
> > I'm having some apps running on my desktop that all want
> > exclusive access to my sound device just for playing audio
> > (and a single app for capturing), namely:
> >
> > * TeamSpeak (VoIP team voice chat)
> > * Cedega (for playing some win32 games on my beloved box)
> > * KDE/arts (my desktop wants to play some sounds as well wtf)
> >
> > While I could easily disable my desktop sounds, and yeah, forget about the
> > music, but I'd still like to be in TeamSpeak (talking to friends and alike)
> > while playing a game using cedega.
> >
> > Unfortunately, *all* those stupid (2) apps want exclusive access to the OSS
> > layout of my ALSA drivers, though, there just came into my mind to buy a
> > second audio device and wear a second headset (a little one below/under my
> > big one). But I couldn't find it handy anyway :(
>
> This problem is (mostly) solved already. You have to use aoss (alsa-lib
> based OSS emulation) on top of dmix (software mixing for soundcards too
> lame to do it in hardware). With a recent ALSA dmix is already used by
> default so the only change needed is to launch the OSS apps with the
> aoss wrapper e.g. aoss ./foo-oss-app. Since it's not completely
> transparent this problem will have to be solved at the distro level, by
> making sure all OSS apps are run with this wrapper.
>
> This method should only be needed for closed source apps, an open source
> app like artsd should be ported to use the ALSA API.
Also note that we have Open Sound System call redirector in our alsa-oss
package (see http://www.alsa-project.org for download). It's small library
which can redirects OSS calls to any dynamic library.
It would be nice to convert existing OSS apps to use this library. It
should be quite fast and easy. The only thing is to persuade sound
developers to use this library instead the direct open/close/ioctl
OSS syscalls.
Jaroslav
-----
Jaroslav Kysela <[email protected]>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs