Open Sound System

Just and idea. I heard somewhere that it's possible to run two linuxes simultaneously. One OS1 has alsa and jack for making music, the second OS2 has only OSS for high quality playback. One folder of OS1 is shared to OS2, so flacs in it are immediately accesible for OS2 for playback. I think this can already be implemented via QubesOS which is based on Xen. Unfortunately my CPU is old and does not support features needed for qubesos installation (requires i5 or higher cpus). If you have such cpu you may try to make a guide for people. And one even more interesting idea: we can stream the final mixed stream via ip streaming from OS1 via ip/udp protocol directly to the recieving application installed in OS2 and in this case WE CAN USE OSS FOR PRODUCTION WITH JACKD OR ANYTHING WE WANT WHICH REQUIRED ALSA. This way we can enjoy all strong features of high quality of OSS and the same time utilizing the jackd and midi possibilities of alsa.
Now it's left only to the technical side. How to implement this. Guide is required.

But i wonder if the same soundcard can handle working for two OSes with two drivers simultaneouly. Otherwise two soundcards are required where only card1 is visible to OS1 and card2 is only visible to OS2. This is not expensive. For example, you use integrated intel HDA on OS1 and audigy2 on OS2 or vice versa. Of course the card for OS2 must have better DAC because it's used for playback. But card for OS1 must have stronger processors to handle jackd's requirements.

You do not need two OSes, you can simply tell OSSv4 to use only first sound card and ALSA to use only second, of course if you do have two sound cards, which isn't that rare these days since literally every desktop motherboard have a built in sound, as crappy it might be, it's still a "sound card" and if you are interested in "a bit of quality sound" like OSSv4 then most likely you already have a normal sound card.

hash wrote:You do not need two OSes, you can simply tell OSSv4 to use only first sound card and ALSA to use only second, of course if you do have two sound cards, which isn't that rare these days since literally every desktop motherboard have a built in sound, as crappy it might be, it's still a "sound card" and if you are interested in "a bit of quality sound" like OSSv4 then most likely you already have a normal sound card.

It might be problematic to load evil ALSA drivers together with OSS4 drivers.
Although of course, it is possible to load some "harmless" ALSA drivers together with OSS4.

EXAMPLE (OSS4 + snd + soundcore): _http://www.opensound.com/forum/viewtopic.php?f=3&t=5204&p=19271

Well, I've recreated setup proposed by me, and it work flawlessly with some quirks..
Thanks for the link, by the way, it helped me to streamline the start-stop of alsa part.

So I needed ALSA for TeamSpeak3 (TS3), and I got my self the following setup:
My Creative "SoundBlaster Audigy Gamer 2" is served by OSSv4 only.
My built in "HD Audio Intel PCH ALC892" is served by ALSA only.
Everything play trough OSSv4 and 99% of programs uses microphone input of OSSv4.
TS3 uses ALSA for microphone input and OSSv4 for all output.
What I've done:
1. We need to make sure that ALSA loads all it's needed modules and ONLY needed modules for ONLY ONE sound card so what I did:

1.1. Removed OSSv4 service from starting at all.

1.2. Recompiled kernel with ALSA modules compiled as modules.
I compiled only modules Intel HDA needed as I knew which it needs but if you don't know which modules are needed and which is not You can compile all ALSA as modules or in case of binary distribution like Debian/Ubuntu, Fedora/CentOS, etc you'll have all ALSA modules compiled for you so this step can be safely ignored in this case.

1.3. I knew what modules needed, but in case you don't, you can simply temporary remove the other sound card, in my case that would be my Creative "SoundBlaster Audigy Gamer 2", and restart computer, upon completed start udev will load all needed ALSA modules, you should make a note of which modules needed with command thing like this:If at this point you'll find that non of them are loaded then check if they are blacklisted some where in /etc/modprobe.d/ and temporary comment out that blacklist, you will need that blacklist down that road.

1.4. Now I needed the correct rmmod command because rmmod command cannot unload module if it is used by any other module so you need to tell rmmod in which sequence to unload modules by hand so it unloads only modules that aren't used by any one, you can check which module uses which with lsmod mentioned before, I get thisAnd I needed a command to load all needed modules, that is much easier in my case this worked:You might want to test this after you blacklisted all ALSA modules as blacklisting affects autoload of modules with modprobe command in My case without blacklist it was enogth to load only snd_hda_intel ans after it wasn't, you can check if ALSA modules is loaded correctly withit should list your desired sound card.

1.5. Now I had all needed info about ALSA and should blacklist all ALSA modules (in my case: /etc/modprobe.d/blacklist-alsa.conf), add back OSSv4 service to be loaded on start, re-plug sound card in PC and reboot it.

2. Now I need make sure that OSSv4 do not try to load module for Intel HDA which is much simpler task than with ALSA.
Just edit and remove any lines not related to the one sound card you need OSSv4 to use. In My case all I left
3. And now I needed to automate restart of OSSv4 service, as it noted in topic you gave me the link to, /usr/sbin/soundon command actually removes all ALSA modules backing them up, thankfuly, in "/lib/modules/`uname -r`/sound-preoss.tar.bz2", but I want to prevent this from happening at all, at system startup this will not happen because of ALSA modules blacklisted but if I am to restart OSSv4 service, that might happen, and so I made sure that in no case any of ALSA modules are loaded at the time of soundon is executed.
I've achieved that by adding rmmod line I've got earlier to service script in "/etc/init.d/oss" right before soundon command.
It is not enough to add rmmod line in /usr/lib/oss/soundon.user as that script is started by /usr/sbin/soundon after ALSA modules detection and removal.
3.1. Also I've added to the end of /usr/lib/oss/soundon.user:So that uppon start of OSSv4 I have ALSA started and fully configured ALSA mixer and I've actualy configured ALSA volumes with alsamixer command so that all capture I need is on and at good volume level and no other is on at all, just muted everything else.
4. And last thing is /etc/asound.conf ( or ~/.asoundrc) which ever fly you boat, that works for me:

Now main "quirk" for me is that for everything I use microphone in my wireless headset but for TS3 I have to use microphone sitting on top of my monitor, not so convenient...
That could be solved if instead of another microphone I've used Line-Out of my Creative sound card looped in to Intel HDA Line-In, that could work really well from ALSA part but I have no idea of how can one copy all that comes in microphone port of a card in to Line-Out port of the same card in OSSv4.

hash wrote:...but I have no idea of how can one copy all that comes in microphone port of a card in to Line-Out port of the same card in OSSv4.

You may try HW mixing with OSS4. It works with some soundcards.

Many drivers offer support for loopback recording via the hardware. This is typically done with the 'vol' mixer control. If this can be used as a recording source, than the current sound output will be recorded. Note that this is the mixed total of all sound played, not of a single program.

Code: Select all

ossmix vol.rec ON     #sets 'vol' as default target, so any recording program uses it by default
ossrecord blah.wav

Some drivers have a 'loopback' mixer control (instead of 'vol'), which offers similar functionality. This can be set by ossmix or ossxmix mixer control programs.
_http://www.opensound.com/wiki/index.php/Tips_And_Tricks#Recording_sound_output_of_a_program

NOTE: It records not only "the mixed total of all sound played", it records everything (including microphone).
So that you can play music with several players through Skype (+ input of your mic), and record everything (including all Skype input/output) with Audacity
(vmix is enabled).

"vol.rec" is for AC'97 codecs

"input-mix-mut" or "input-mix-mute" for Intel HDA codecs

EXAMPLE:



See also: _https://wiki.archlinux.org/index.php/Open_Sound_System#Microphone_playing_through_output_channels

EXAMPLE: Creative Audigy 4
_http://www.opensound.com/forum/viewtopic.php?f=3&t=4656

HW mixing is easy to detect:
1. Plug a microphone into your PC.
2. Speak into the microphone (but do not run any recording software).
3. Try different settings in ossxmix.

If you hear your voice in the speakers, it means that HW mixing is enabled.

WARNING: It seems that the only safe way to load ALSA is to load it together with the Linux system.
If you load ALSA manually, you may get problems (e.g. "underruns"),
see: _http://www.opensound.com/forum/viewtopic.php?f=3&t=3981&p=15880#p15880

You may better "correct" the "soundon" script to disable "removal of ALSA modules".







“if !” _http://unix.stackexchange.com/questions/162809/what-does-if-mean

Underruns happens only with playbacks and I do not need that from ALSA atm.
That "support for loopback recording via the hardware" in case of Creative sound cards is called "record all you hear" and is useless in my case as I need to "copy" all that received on microphone jack in to Line-Out of the same sound card (Creative), the i'd plug Jack-to-Jack from Creative sound card in to Line-In of Intel HDA.

In ideal world We wouldn't need all this.
We'd just had a virtual ALSA sound card shipped with OSSv4 like a module, some thing like snd_virtual.ko compiled at the same time as all other OSSv4 modules and We could just tell which of source to link to in and out of that virtual ALSA sound card, and it would fork it self on any application attempting to use it so that We'd have adequate representation of all such applications in ossxmix, and that virtual ALSA sound card would announce that it do not have hardware mixing so that We wouldn't need to worry our self with many applications trying to open same virtual ALSA sound card at the same time and bother our self with dealing with all race conditions and necessity to mix all that in additional software mixing module as it would be handled by OSS's vmix.
In ideal world...

hash wrote: I need to "copy" all that received on microphone jack in to Line-Out of the same sound card (Creative)

This command copies "all that received on microphone jack" into my earphones (so that I can hear my voice in the earphones):

Of course that will, but that mean that I'll need to add that as a constant background process and make sure it runes all the time I use TS3 and shut it down in case I need to restart OSSv4 service, so more addition in service file...
A bit of cumbersome solution.

hash wrote:A bit of cumbersome solution.

Another "cumbersome solution" might be


In both cases, you may use different devices (and jacks) for input and output.




If I understood you correctly, you do not load ALSA modules for OSS emulation. Right?
I mean snd_seq_oss, snd_pcm_oss and snd_mixer_oss
_https://wiki.archlinux.org/index.php/Advanced_Linux_Sound_Architecture#OSS_compatibility

It seems that your TeamSpeak3 (TS3) is using real OSS4 (that is, /dev/dsp in your asound.conf), instead of OSS emulation. Right?

The question is: Have you tried to capture sound from the same /dev/dsp with TeamSpeak3 (that is, /dev/dsp of real OSS4)?

Of it works, you may not need to load snd_hda_codec_realtek and snd_hda_intel.
A few "harmles" ALSA modules might be sufficient (e.g. snd_pcm, snd_timer, snd).

I am rather ignorant of ALSA config alchemy, but a simple ALSA config may do the work:



_http://www.4front-tech.com/wiki/index.php/Tips_And_Tricks#ALSA_Emulation

WARNING: If you are using a sort of "emulation" with asound.conf, you may better recompile all you audio applications (which support OSS4) to disable ALSA. Otherwise, they may try to use the asound.conf for "emulation", instead of using OSS4 directly.

I hoped that this will work, no dice.
I've learned the hard way that in both ALSA and PulseAudio, support, if any, for OSSv4 is confined by output, there is literally NO support for microphone or any type of input in there.
And if in case of Skype, there simply no sound for input, for TS3 If a try to use this setup, TS3 simply Segment out.

hash wrote:I hoped that this will work, no dice.
I've learned the hard way that in both ALSA and PulseAudio, support, if any, for OSSv4 is confined by output, there is literally NO support for microphone or any type of input in there.
And if in case of Skype, there simply no sound for input, for TS3 If a try to use this setup, TS3 simply Segment out.

Skype does work with OSS4 through the help of a magic tool called "skype_oss_wrapper"
_http://www.opensound.com/forum/viewtopic.php?f=3&t=5762
It works well, although there might be some problems which are easy to fix
_http://www.opensound.com/forum/viewtopic.php?f=3&t=5795

However, the much desired "TS3 wrapper" failed to materialize.

The so-called "ALSA Emulation" seems to work for playback, but it usually fails for recording
_http://www.4front-tech.com/wiki/index.php/Tips_And_Tricks#ALSA_Emulation

There was a hope that some "harmless" ALSA drivers may fix the problem...
If recoding works with OSS emulation, it may also work with the real OSS4 (provided that some magic rituals are correctly performed).

skype_oss_wrapper is already in use.
OSS Emulation isn't going to work with recording simply because it wasn't designed to, through my attempts of getting Skype/TS3 to work with OSSv4, I've come around the documentation along side with blog post which in essence explained exactly that, no recording at all there are simply nothing there to work.
It wasn't post about OSS in any form, main problem is module dsnoop which should work in the same way as dmix but it isn't, it's plainly not developed to work the way we need.