Open Sound System

Hi!




USING ONLY OSS (latest mercurial install) - NO ALSA

I need to be able to have a skype-oss or voip (oss) conversation and while playing a music track INTO the conversation record the whole thing as as podcast.

Need config ideas or if it's even possible. I'm reading this tonight though don't think I'm skilled enough to get my config happening just yet.
Terrific documentation I'd say:
http://manuals.opensound.com/developer/full_duplex.html
http://manuals.opensound.com/usersguide/oss_imux.html

SO:
Could anyone please tell me any of the finer points for writing configs or whatever to get OSS to do this?
I would have to use the loopback I think as I need ot have music going INTO the microphone channel along with my speaking.

I could not use my USB headset for this with ALSA and that's fine for OSS as well.
I think I will have to use some combination of loopback vmix userdev .....

IS this POSSIBLE??? please let me know. If it's not possible I could really use knowing as soon as convenient.

I'd guess that it is though. :----))))


I got podcasts with music working with ALSA (incredibly hellish though nerds are nerdZ - we never quit!!)
It took a couple of 100 hours and over about 2 months figuring out how to create an alsa .asoundrc and also to install aloop and then ask and try ask and try until I got it to play music while talking, and record the whole thing as a podcast.
SO: must now do with ONLY OSS:


Need to use just real card and loopback I think.
Have music played during conversation with mplayer and record the whole podcast with ossrecord I guess.
It's the routing that's REALLY the problem for sure.


ossinfo (blaster 5.1 card and cmedia USB headset)

Number of audio devices: 12
Number of audio engines: 17
Number of MIDI devices: 1
Number of mixer devices: 2


Device objects
0: osscore0 OSS core services
1: oss_sblive0 SB Live interrupts=220388 (220388)
2: oss_usb0 USB audio core services
3: usb0d8c000c-0 C-Media USB audio
4: usb0d8c000c-1 C-Media USB audio
5: usb0d8c000c-2 C-Media USB audio
6: oss_audioloop0 audioloop
7: oss_userdev0 User space audio driver subsystem

MIDI devices (/dev/midi*)
0: SB Live external MIDI (MIDI port 1 of device object 1)

Mixer devices
0: SB Live (STAC9708) (Mixer 0 of device object 1)
1: C-Media USB audio (Mixer 0 of device object 3)

Audio devices
SB Live main /dev/oss/oss_sblive0/pcm0 (device index 0)
SB Live main (vmix) loopback record /dev/oss/oss_sblive0/loop0 (device index 1)
SB Live front out /dev/oss/oss_sblive0/pcm1 (device index 2)
SB Live side out /dev/oss/oss_sblive0/pcm2 (device index 3)
SB Live center/lfe out /dev/oss/oss_sblive0/pcm3 (device index 4)
SB Live 5.1 output device /dev/oss/oss_sblive0/pcm4 (device index 5)
C-Media USB audio play /dev/oss/usb0d8c000c-1/pcm0 (device index 6)
C-Media USB audio rec /dev/oss/usb0d8c000c-2/pcmin0 (device index 7)
Audio loopback 0 server side /dev/oss/oss_audioloop0/server0 (device index
(Audio loopback 0 /dev/oss/oss_audioloop0/pcm0 ) (device index 9)
User space audio device client side /dev/oss/oss_userdev0/client (device index 10)
User space audio device server side /dev/oss/oss_userdev0/server (device index 11)

Nodes
/dev/dsp -> /dev/oss/oss_sblive0/pcm0
/dev/dsp_in -> /dev/oss/oss_ich0/pcm0
/dev/dsp_out -> /dev/oss/oss_ich0/pcm0
/dev/dsp_ac3 -> /dev/oss/oss_ich0/pcm0
/dev/dsp_mmap -> /dev/oss/oss_ich0/pcm0
/dev/dsp_multich -> /dev/oss/oss_ich0/pcm0

The wiki can help you a bit regarding loopback:

http://www.opensound.com/wiki/index.php ... _a_program

What you are trying to do is more complicated than loopback though. You're not just trying to pipe a program's sound output to another program's input (very doable in OSS - you can even have several separate "pipes" and/or multiple programs getting the input from a single program and/or format conversion during the "pipe") or to record from a single source several times (vmix already allows this, but oss_imux will also work) but also to multiplex different inputs (which is quite difficult in OSS, AFAIK).
[Edit: I may have misread you a bit. You're also trying to record both voip input and output, not just have music in voip input?]
I have some ideas though:

A. I don't have an sblive card, so can't test this hypothesis, but I think your sblive card can multiplex passthrough input with output _and_ can record its total mixed output, so you can use a simpler setup than a general OSS solution would have (that might be option "B" below) if you choose. Important: it's likely that this setup has the following restriction: the voip's program output must not be the sblive's pcm0 or maybe not the sblive at all! (i.e. you may have to use the onboard or USB for voip's sound output, and the sblive for voip sound input for this option to work). You'll see why below...

The "oss_sblive" man page says under "SBLive recording":

oss_sblive.man wrote:Turn down the AC97 control in the "record" section. This prevents any audio being fed to the soundcard from MIC/Line-in/CD-in from getting mixed with the audio produced by the application that's currently playing.

This is an advice you will not want to follow. If you don't turn it down, but in fact set mixer up so that mic passthrough happens while ac97 is up, than the passthrough input will be mixed with the output, which happens to be the sort of multiplexing you want (as I said earlier, converting output to input is relatively easy. It's the input mux which is the big problem for us with OSS)... So set up mixer accordingly so passthrough happens. You can at will play something to sblive's pcm0, so we get a mixed output!

Now we want to record the mixed output. I am pretty sure that this mixing happens _after_ vmix (in card hardware), so you can't record this output from vmix loopback. Instead, the 'vol' target should work (your sblive card is AC97 based per ossinfo, and those typically have a 'vol' source to record played output. It's possible the warning above referred to the 'mic' source though - test this). Set the proper source as default recording source via oss(x)mix. Now have the voip program record from pcm0. When/if you want to play a file during voip, just play it to the sblive's pcm0 (your default /dev/dsp as it happens) and it will come up to the voip program's input. Since the cards passthroughs the input and mixes it to its output and the output goes to voip input, the mic will also show up in voip chat. You can also record the voip input simultaneously, e.g. just run 'ossrecord' on the same input node.

Before that though we have to set up the voip's output to your computer, which is a bit of a problem. I worry that If it also goes via pcm0, you could get feedback, which I guess is probably very bad... It's possible this will work, or you can use a different sblive output (pcm1/pcm2 etc.) to get voip sound output from the sblive without it being recorded via 'vol, but be very careful here. You can test this setup safely first by having the voip output to ich onboard/USB [Edit: If you want to record both voip input and voip output together, I think you'll have to use vmix loopback. it's the setup above + this:

Code: Select all

skype/voip whatever output + echo loop from 'vol' target recording -> output node with vmix and vmix loopback somewhere -> recording program

.]

A problem here is that some voip programs don't allow setting separate input and output nodes... vmix routing can help here and the wiki has a bit on that too in the first tip on that page (i.e. "vmixctl attach" using sblive's pcm0 for input and a different node (say ich's pcm0) for output, and set up the program to use the ich's node. vmix should route the input to use the attached sblive input).

B. General hack: Route mic input to output, and use OSS's vmix (or other methods) to multiplex, then make that voip input. I guess this is what you had in mind with your vmix loopback idea. Note that if you're using vmix, you won't be able to use the output used for mixing for "real" stuff for same reason as above (and vmix doesn't attach to "virtual" outputs so we can't fake an output). This is less of a problem here though, since you can pick an output which isn't normally used (e.g. SBLive's side out) and play to that, leaving your main output clear.

Setup can go like this:

Code: Select all

echo loop for mic. +  (program to play sound files) -> mixing layer (e.g. vmix) -> recording/input node (e.g. vmix loopback) -> skype/voip whatever

echo loop for mic can be something like "ossrecord -FAU - | ossplay -". This is done to pass mic input to some mixable state since passthrough doesn't pass via vmix (and most cards can't record/mix own output - this may not be true in your case as I wrote above in option "A"). You may have to use '-d' switch for ossplay or ossrecord, especially if you use a side node for vmix. Unfortunately, I don't know of a way to convert input to output beside variations of this (or of in-card route tricks as earlier), and an echo loop can introduce latency... It can probably be done a bit more efficiently, without the pipe.

mixing layer can be vmix, but doesn't have to be (e.g. you may use some sound server like jack/pulse to mix and than link via oss_audioloop/oss_userdev. this will of course require different echo loop etc.).

This wiki page shows how to enable loopback. Note that if you're attaching a new vmix instance, I strongely suggest you attach an input node as well (otherwise programs opening device in O_RDWR mode fail).

Lastly, voip program will be set up to listen on the vmix loopback (or other) node. [Edit: I think you can set up ossrecord to record from that node if you want to record your input. If you want to record both voip input and voip output, we'll need a more complicated setup, basically the first setup above + this:

Code: Select all

skype/voip whatever + echo loop from first vmix loopback -> second vmix loopback

and then record from second vmix loopback.]

C. If neither of these work/good enough for you, you may also want to ask the devs in the oss-devel list for ideas...

UPDATE COMMENT: have now begun to re-read well your terrific reply. Thrilled that you have knowledge on OSS. I hunt around looking for some tip here and there.
I have moved the SBlive5.1 to another PC which has different internal audio chip. Though as noted below I should really find a way to do this with just one internal audio and software mixing. oh, and only OSS without pulseaudio etc.

The netbook I will use is going to have ICH9 and I guess that'll be intel hda of some sort I guess.

----- INITAL TEXT BELOW---
just got your reply cesium ! very very VERY cool/kind, thank you. So, I have only scanned your post though a couple of thoughts.

- I like OSS as it's linux and bsd and clear etc. etc.
- I am looking for a software only solution using similar things that I had 'finally' working with alsa, because I need to be able to record podcast on more than one machine and the netbook will not have 2 cards or 'real' hardware mixing.
- With alsa along with default dmix and dsnoop (output and input multiplexers?) I used a vitualcard driver called snd_aloop, I had to use it with the laptop's internal sound card as USB headset didn't have the electronics I guess to do this:

(this took me forever to figure out though I'm smarter now I guess with OSS because of it)

At just about the same time, after starting a skype conversation, I would start recording audio and also playing music track audio. I used command line player recorder and player programs. arecord / aplay etc.

I'd end up with a stereo file that had the the chat and the music.
Also, during the skype chat the music could be heard by me and the person I was speaking to. So the music was getting to my headphones and also must have been going down the same way my microphone was, if that's clear enough.

So, I'm hoping to find out (haven't read all your post well at all yet) IF there's some kind of oss.conf file that can be written to create the interplay between virtual sound cards / loopback etc. in OSS.

I'll write back soon, and also I think I need to select 'Notify me when a reply is posted' as it appears not to do that automatically.

So, yes, I am really really hoping this can hgappen before weeks go by. hehehe
it was an immense struggle with alsa.

P.S. I think google voice/gizmo or another sip program might replace skype someday soon-ish. Skype really seems to need to 'think' it has full control over a card. I set skype's input to an alsa device that was created out of a combination of the virtual-soundcard and the internal (hda-intel) soundcard's mic input (no usb at all - the analog input). Had to install the alsa sound driver 'aloop to get the virtual card.
By comparision OSS feels very nice regardless of the outcome of my requirements here wit currently having to use Skype etc.

NOTE 1 added: haven't managed to get my cmedia headset's mic to work. Could be just me though as can't say it's not working for sure, just that skype doesn't like it at all.

NOTE 2 added: As I can hear the music and both sides of the conversation IN my headset (non-usb stereo headset speakers and mono microphone)
By recording a parallel copy (virtual-card/loopbacks/vmix?) of all my headset's audio everything would be there in podcast?

I think I can summarize my post above:
I don't know of any way to do input mixing (i.e. mix input from two different sources and use that as input for something else) directly with an OSS only solution**, so I suggested routing/sending input to output, doing output muxing and then use that as input.

This is done once for mixing music with mic input in skype input, and a second time to allow recording of entire chat. This is a horrible hack***, especially since mixed input in this method may come out of sync (and I'm not sure about latency) and maybe you can ask the devs in oss-devel if there's an easier way. I also wonder whether there isn't a voip program which can do chat recording etc. for you without messing with sound system....

** oss_imux/vmix are used to allow several clients to use same input and/or to convert input to format desired by client, but do not allow merging of several input to one input.

*** ok, I think the sblive hardware solution would be acceptable if I only wanted to do this once for voip input... [Edit: especially since there are no sync requirements for music and mic input, I guess...] Now that I see that you want to record chat as well, you'll need a second iteration [Edit: if you can hear the entire chat, than maybe not].

I am not sure I understand your NOTE 2 above. Once you have an input, any** number of clients can record it if vmix or oss_imux are attached to the source. [Edit: I got this wrong]So if you can hear the entire conversation in the headset you can record a parallel copy, as long as vmix or oss_imux are attached to the card/node which you use to record from the headset.[/wrong]
[Correction: Any output which isn't passthrough can be recorded via vmix loopback, the input discussion isn't relevant. If you can hear this, this is output, and most likely passes via vmix, which means vmix loopback will work to record this] This can be used to mostly skip the second iteration of the trick above [Edit: since there's no need to mux the voip output with the voip input. Instead, we can just record from vmix loopback], but we'll still need some effort to mix in the music to the voip input (i.e. the non-edited parts of my first post).

** ok, not any, but a reasonable number.

I edited in a correction to my post above.

I'm keeping in mind when I write, that although I managed what was happening when I used .asoundrc in alsa (with just the internal intel-hda card and the virtual-card loopback)
I have a hard time being accurate explaining it, if that makes sense.

I'm saying: (for example) I probably didn't mean to suggest that I pre-mixed to inputs then fed them to a sound device in software.

Your 'correction' is brilliant. OSS is so flexible and clear. I'm feeling more and more steeled to figuring out and staying into OSS. (plus I'm getting closer to having an 'in parallel with my linux system' working freeBSD system as well :--)

SO: I think it would be sensible/respectful if I figure out the differences with OSS and then write back with more understanding. Today (day 2 of OSS for me, hehehe) I'm stumbling with terminology on an already patchy understanding. I'm commited on this one. I love the way OSS makes sense. /dev/dsp um, cool!

I just need to start by finding out hOw I cable stuff together. All I've found so far is the wonderful config files. I need to read your replies closely and also deduce how one would actually patch something together as discussed here.

Yes, that's where I'm at. I seen to imagine things as way more complex than they actually turn out to be, from a uses point that is. So right now I'm drowning in unknowns, sorta.

Gonna read and look for how to translate all the wonderful terms and routing examples/tests here into some kind of...uhhhh, master-config is it?

NOTE ADDED: yes, there is no 'sync' required nor latency concerns for the music and voice input streams. And, sample rate etc. hasn't been a problem for me with alsa and it won't be with OSS either from what I'vededuced.

P.S. I felt a bit painted into a corner that all my alsa struggles and success were stuck with linux. Of course, the learning was great, (essential even - yet over 6 weeks trying to get info - sheesh) and alsa's fine and all. I'm saying this is really really great. So grateful for all this motion in ONE day. um, yeah, lotsa greats!

Now off ot the wiki, the devel list, and the forums here 'till I understand how to try to translate your ideas to the config-files or something.

Well, I should have explained it earlier, but OSS doesn't have a parallel to .asoundrc config file.

Configuration is as follows:
A) Symlinks from /dev/oss. Mainly /dev/dsp symlink which is the default output/input for most programs.
B) vmixctl utility controls several vmix settings and can be used to attach vmix to other devices (it only attaches to some devices by default. ossinfo output (especially ossinfo -v2) can show you where it's attached).
C) oss(x)mix controls mixer settings, which includes some vmix settings too.
D) Files sourced or used by soundon startup script when OSS is started, or OSS module parameters:
1) installed_drivers - list of OSS modules to load. Usually created by "ossdetect" utility.
2) conf files are converted to module parameters by soundon. They mostly control some behaviours of specified module (each module has a manpage which should tell you if/what can be configured). Exception is osscore.conf which controls some settings shared by modules or general OSS settings which are set at startup.
3) soundon.user is sourced by soundon, to run user commands after OSS startup.

There isn't much of a "routing" ability unfortunately:
1) vmix has ability to create one or two input nodes which can be used to record the output going via vmix. It's mainly used to mix multiple clients' output, and to allow multiple clients to use same input (both with format conversions if needed).
2) oss_userdev and oss_audioloop can be used to make sound "pipes" between programs. oss_userdev is more complex to set up, and allows some more stuff (like a "server" emitting sound to multiple "clients", or format conversions for clients). There is no network support in the modules, so server and clients can't be on different machines unless one wants to play with netcat etc. (maybe the right userland server can do this with oss_userdev? In any event, there are much better solutions than this for network streaming).

WOW, thank you! So, don't need network support. scripts good! Need to be able to have OSS running on netbook with ICH9 / hda-intel and do the skype thing. (hopefully replace skype later)

So far (last night) I tried to get skype to use oss_audioloop I think it was... only this didn't work the way I had it set in skype audio devices. Skype would hang after first 'echo' call test. Maybe I only had half of it set. skype fine with /dev/dsp. problem was when I tried the cmedia USB actually now that I recall. will have to actually assertain IF the headset mic does work with OSS. Speakers of USB headset DO work. I've read a bit about this though I never assume, much.

Here I go filling up the forum, which is possibly way more interesting than my rambles.:--)
um, I have an imux0 and a vmix loopback. I turned off the internal soundcard and unplugged the USB cmedia headset, so for real harware it's the sbLive-5.1 card.
With skype I don't think all the devices show up in either in or out in skype's audio devices pull down menus.
any idea what i'd use for in and what I'd use for out, considering I'd want to at least get the music track playing INTO the mic line somehow, eventually. I need to be able to hear the music also.

HUGELY interested, with thanks.

[oss_emu10k1x]
I'm pretty sure the SBlive5.1 uses the _oss_emu10k1x driver. Let it as it was though.

Below are 'shot in dim light' attempts at altering the .conf filies.
[oss_audioloop]
audioloop_instances=2
[oss_imux]
imux_devices=2
[oss_core]
vmix_loopdevs=1


[ ossinfo -v2] (removed midi device text etc. short as I could make it)

Version info: OSS 4.2 (b 2002/200912190217) (0x00040100) OSS_HG
Hg revision: changeset: 875:caabde71b56

Number of audio devices: 7
Number of audio engines: 12
Number of MIDI devices: 1
Number of mixer devices: 2

Device objects
0: osscore0 OSS core services
1: oss_sblive0 SB Live interrupts=11262 (11262)
2: oss_usb0 USB audio core services
3: oss_imux0 OSS IMUX driver

Mixer devices
0: SB Live (STAC9708) (Mixer 0 of device object 1)
Device file /dev/oss/oss_sblive0/mix0, Legacy device /dev/mixer2
Priority: 2
Caps:
Device handle: PCI80641102-0000:00:0b.0-mx01
Device priority: 2

1: IMUX Control panel (Mixer 0 of device object 3)
Device file /dev/oss/oss_imux0/mix0, Legacy device /dev/mixer3
Priority: 0
Caps:
Device handle: oss_imux0-mx01
Device priority: 0


Audio devices
SB Live main /dev/oss/oss_sblive0/pcm0 (device index 0)
Legacy device /dev/dsp3
Caps: DUPLEX TRIGGER MMAP
Modes: IN/OUT
Engine 1: 0/SB Live main
Available for use
Engine 2: 1/SB Live main (vmix)
Available for use
Engine 3: 2/SB Live main (vmix)
Available for use
Engine 4: 3/SB Live main (vmix)
Available for use
Engine 5: 4/SB Live main (vmix)
Available for use
Formats: 0x10 in, 0x418 out
Device handle: PCI80641102-0000:00:0b.0-au01
Related mixer dev: 0
Sample rate source: 0
Preferred channel configuration: Not indicated
Supported number of channels (min - max): 1 - 2
Native sample rates (min - max): 8000 - 48000 (8000,11025,16000,22050,24000,32000,44100,48000)
HW Type: Not indicated.
Minimum latency: Not indicated

SB Live main (vmix) loopback record /dev/oss/oss_sblive0/loop0 (device index 1)
Legacy device NONE
Caps: BATCH TRIGGER MMAP MULTI VIRTUAL HIDDEN
Modes: INPUT
In engine 1: 5/SB Live main (vmix) loopback record
Available for use
Formats: 0x10 in, 0x10 out
Device handle: PCI80641102-0000:00:0b.0-au02
Related mixer dev: 0
Sample rate source: 5
Preferred channel configuration: Not indicated
Supported number of channels (min - max): 2 - 2
Native sample rates (min - max): 48000 - 48000
HW Type: Not indicated.
Minimum latency: Not indicated

SB Live front out /dev/oss/oss_sblive0/pcm1 (device index 2)
Legacy device /dev/dsp4
Caps: TRIGGER MMAP
Modes: OUTPUT
Out engine 1: 6/SB Live front out
Available for use
Formats: 0x10 in, 0x418 out
Device handle: PCI80641102-0000:00:0b.0-au03
Related mixer dev: 0
Sample rate source: 0
Preferred channel configuration: Not indicated
Supported number of channels (min - max): 1 - 2
Native sample rates (min - max): 8000 - 48000 (8000,11025,16000,22050,24000,32000,44100,48000)
HW Type: Not indicated.
Minimum latency: Not indicated

SB Live side out /dev/oss/oss_sblive0/pcm2 (device index 3)
Legacy device /dev/dsp5
Caps: TRIGGER MMAP
Modes: OUTPUT
Out engine 1: 7/SB Live side out
Available for use
Formats: 0x10 in, 0x418 out
Device handle: PCI80641102-0000:00:0b.0-au04
Related mixer dev: 0
Sample rate source: 0
Preferred channel configuration: Not indicated
Supported number of channels (min - max): 1 - 2
Native sample rates (min - max): 8000 - 48000 (8000,11025,16000,22050,24000,32000,44100,48000)
HW Type: Not indicated.
Minimum latency: Not indicated

SB Live center/lfe out /dev/oss/oss_sblive0/pcm3 (device index 4)
Legacy device /dev/dsp6
Caps: TRIGGER MMAP
Modes: OUTPUT
Out engine 1: 8/SB Live center/lfe out
Available for use
Formats: 0x10 in, 0x418 out
Device handle: PCI80641102-0000:00:0b.0-au05
Related mixer dev: 0
Sample rate source: 0
Preferred channel configuration: Not indicated
Supported number of channels (min - max): 1 - 2
Native sample rates (min - max): 8000 - 48000 (8000,11025,16000,22050,24000,32000,44100,48000)
HW Type: Not indicated.
Minimum latency: Not indicated

SB Live 5.1 output device /dev/oss/oss_sblive0/pcm4 (device index 5)
Legacy device /dev/dsp7
Caps: TRIGGER MMAP
Modes: OUTPUT
Out engine 1: 9/SB Live 5.1 output device
Available for use
Formats: 0x10 in, 0x10 out
Device handle: PCI80641102-0000:00:0b.0-au06
Related mixer dev: -1
Sample rate source: 6
Preferred channel configuration: MULTICH
Supported number of channels (min - max): 2 - 6
Native sample rates (min - max): 8000 - 48000
HW Type: Not indicated.
Minimum latency: Not indicated

IMux0 audio record /dev/oss/oss_imux0/pcmin0 (device index 6)
Legacy device /dev/dsp10
Caps: TRIGGER VIRTUAL
Modes: INPUT
In engine 1: 10/IMux0 audio record
Available for use
In engine 2: 11/IMux0 audio record
Available for use
Formats: 0x10 in, 0x10 out
Device handle: oss_imux0-au01
Related mixer dev: 1
Sample rate source: 10
Preferred channel configuration: Not indicated
Supported number of channels (min - max): 1 - 2
Native sample rates (min - max): 5000 - 192000
HW Type: Not indicated.
Minimum latency: Not indicated


Nodes
/dev/dsp -> /dev/oss/oss_sblive0/pcm0
/dev/dsp_in -> /dev/oss/oss_ich0/pcm0
/dev/dsp_out -> /dev/oss/oss_ich0/pcm0
/dev/dsp_ac3 -> /dev/oss/oss_ich0/pcm0
/dev/dsp_mmap -> /dev/oss/oss_ich0/pcm0
/dev/dsp_multich -> /dev/oss/oss_ich0/pcm0

NOTE ADDED: skype gives me (for both in and out in audio devices) only:

/dev/dsp
/dev/dsp3
/dev/dsp4
/dev/dsp5
/dev/dsp6
/dev/dsp7
/dev/dsp10

who know if there's something skype's mixed up from earlier ossdetect etc.
as an aside, OSS seems to like a reboot after a card is physically installed and detected via OSS software routines.
Can't recall exactly though it's one of those good to know 'nack' things.

Not sure if this still may apply as much.

i.e. you may have to use the onboard or USB for voip's sound output, and the sblive for voip sound input for this option to work). You'll see why below...

With alsa I used the virtual sound card driver 'snd_aloop' and although it doesn't have any volume controls it allowed me to then have a second 'card' available for the mux parts of alsa I think (dmix - dsnoop) to do their in and out stuff while letting skype think it had the card all to itself. um, sorta not explained at all well. anyways, the cmedia headset was one of the things that really slowed me down as in the final result it was unusable with alsa. No actual chip inside the headset I guess. It was one of the main problems with my alsa struggles.

For this to work with OSS it has to ultimately use just the onboard sound chip of a netbook. and of course whatever mux stuff. The alsa solution was just basically a relief after so long at it. it wasn't great, at all.

Number 1 is just getting music to play down the mic line along with speaking. Hear-able both sides of the conversation. This means playing a music track (which will become mono of couse which actually sounds fine) by starting ossplay (maybe with mpg123) or mplayer, after the skype call is connected.

Number 2 is starting ossrecord and creating an audiofile that includes my mic stream and my speakers stream.

I think there should be a way with all you've supplied here. I'm thinking that using only OSS hooks would be best as that way it can be translated to the netbook or laptop easily. Looking to avoid relying on any specific hardware ideally. Right now the SBlive card is in the old desktop. I could remove that and use the internal sound card which is a VIA ac97? type I believe. I should check. It may be better if it's more limited perhaps for testing/trying.

yvon wrote:So far (last night) I tried to get skype to use oss_audioloop I think it was... Skype would hang after first 'echo' call test. Maybe I only had half of it set. skype fine with /dev/dsp

See "oss_audioloop" manpage. The "server" program using one side of oss_audioloop will be suspended until a client will exist on the other side which can "listen". You're probably better off with vmix loopback for this though, since you want also to hear the output from skype...

any idea what i'd use for in and what I'd use for out, considering I'd want to at least get the music track playing INTO the mic line somehow, eventually. I need to be able to hear the music also.

First we want just to get skype to play something at all. So use ordainary /dev/dsp and see if skype-oss works at all.

I'm pretty sure the SBlive5.1 uses the _oss_emu10k1x driver. Let it as it was though.

Let OSS autodetect the card - OSS does this better. The emu10k1x driver is for a special Dell OEM model which is different from regular SBLives.

Below are 'shot in dim light' attempts at altering the .conf filies.

Don't bother with most yet. Just keep the vmix loopback for now and that's it. (The vmix loopback setting should exist in osscore.conf).

as an aside, OSS seems to like a reboot after a card is physically installed and detected via OSS software routines.

No need to reboot - you can restart OSS via "sudo soundoff" and "sudo soundon". After hardware changes you may wish to run "sudo ossdetect -v" to have OSS redetect stuff. I also suggest "sudo ossdevlinks -v -r" after OSS is loaded (just in case).

Btw, if you're loading modules manually after OSS has loaded (e.g. "sudo modprobe oss_imux"), you'll probably want to run "sudo ossdetect -d -v" to create the nodes for them.

I think there should be a way with all you've supplied here. I'm thinking that using only OSS hooks would be best as that way it can be translated to the netbook or laptop easily. Looking to avoid relying on any specific hardware ideally. Right now the SBlive card is in the old desktop. I could remove that and use the internal sound card which is a VIA ac97?

You can, but I'll clarify: I had two ideas. The first relied on using the SBLive to mix the passthrough and the music, and pipe that into skype. If you're trying that way, than it may rely on the card - I'm not sure the internal sound card can do that - you'll have to test that. If that can't be done, you'll have to use the second idea with OSS assuming only the internal card exists (Or some other idea if anyone has any).

Fantastic: I've got tons to work with. I'll do a day or more on looking to piece this together which will be genuinely fun. Very memorable. Amazingly helpful. Biggest thanks. I'll write back smarter (hopefully) in a day or 3 or so. No reply needed to this of course.. Life and those darn time clocks and all-nighter studies. Looking forward to letting you know where I got to with OSS. The oss-devel list is a good read.

NOTE ADDED: just read your above post carefully. Amazing how many points I'd stumbled on that you clarified.

Got EVERYTHING working in 5 minutes. Today I sat down thinking I'd get at least a bit of information from testing. I had thought I'd put the cofigs back to everything 'extra' off as default though I've just checked and there is still:

Code: Select all

core:
vmix_loopdevs=1
audioloop:
audioloop_instances=2
imux:
imux_devices=2

Not sure if any of that makes a difference, though I'll find out at some point.

With just the SBlive5.1 and skype all set to /dev/dsp invoking in one term window "ossplay | mpg123 song1.mp3"
And in another term window invoking "ossrecord pod1"

Start a skype chat and voila, on playback ALL is there.

Interesting is that the equalizer works during the chat though I don't think it records though will try again. Had to post here immediately!

So, now to try the internal via ac97 sound card without the SBlive card to see if this is working due to the SBlive's feature set.
And, the EQ would be very nice to have printing to the resultant podcast audio file.

This is SO incredible. I exhausted weeks fumbling together an .asoundrc with alsa which sounded poor, was not intuitive or manageable, andstuff was panned incorrectly. Not saying it can't be done by a guru much better that I with alsa yet I am astonished that OSS just worked without any thinking/failed attempts whatsoever.

Now to look into the finer points. Mainly, can this be achieved with any card on any machine, and if so, how.

THANK YOU!!!!!!!!!!!!!!

NOTE ADDED: thinking that some 'vmixctl' magic based on the VIA AC97 (ossinfo -V2 below) might give the needed virtual i/o to have this card work like the SBlive did. Also: 'soundconf' is not available I think?

Kinda happy to now konw that I'm going to be learning more about OSS. Using the motherboard's internal sound card VIA823x AC97 mixer (VT1612A):

In ossxmix there's the top section with all the ins and outs - vmix0-channels set to stereo or multich and the vmix0-src, and vmix0 out level twice,, below that the mixext section which has just spkrmode (front or spread) and the 2 checkboxes for mix-lfe2front and mix-rear2front both are unchecked.

NOTE: In skype with the VIA internal card I have just
/dev/dsp
/dev/dsp10
/dev/dsp11


Below that there's the vmix with pcm1 pcm2 pcm3 pcm4

On the 2nd tab in osxmix there's the imux control panel client section with pcm7 and pcm8
So, the question is do I set something different in skype's audio in out like /dev/dsp?
or do I add something specific to ossplay and ossrecord to tap into a specific 'copy' of the in and out streams?

when I do the same test as I did with the SBlive5.1 card (which has 4 extra sections in ossxmix (including the EQ)
I get everything sounding the same and the vmix0 auto updates to give ossrecord, mpg123 (ossplay) and skype twice!

Yet, nothing actually record susing ossrecord yet I hear everything the same as with the SBlive card.
Perhaps I need to change something in the conf files?


Here's the ossinfo -v2
Number of audio devices: 3
Number of audio engines: 9
Number of MIDI devices: 0
Number of mixer devices: 2


Device objects
0: osscore0 OSS core services
1: oss_via823x0 VIA VT8235 interrupts=376563 (376571)
2: oss_usb0 USB audio core services
3: oss_imux0 OSS IMUX driver

MIDI devices (/dev/midi*)

Mixer devices
0: VIA823x AC97 Mixer (VT1612A) (Mixer 0 of device object 1)
Device file /dev/oss/oss_via823x0/mix0, Legacy device /dev/mixer4
Priority: 10
Caps:
Device handle: PCI41611106-0000:00:11.5-mx01
Device priority: 10

1: IMUX Control panel (Mixer 0 of device object 3)
Device file /dev/oss/oss_imux0/mix0, Legacy device /dev/mixer3
Priority: 0
Caps:
Device handle: oss_imux0-mx01
Device priority: 0


Audio devices
VIA VT8235 /dev/oss/oss_via823x0/pcm0 (device index 0)
Legacy device /dev/dsp11
Caps: DUPLEX TRIGGER MMAP
Modes: IN/OUT
Engine 1: 0/VIA VT8235
Available for use
Engine 2: 1/VIA VT8235 (vmix)
Available for use
Engine 3: 2/VIA VT8235 (vmix)
Available for use
Engine 4: 3/VIA VT8235 (vmix)
Available for use
Engine 5: 4/VIA VT8235 (vmix)
Available for use
Formats: 0x418 in, 0x418 out
Device handle: PCI41611106-0000:00:11.5-au01
Related mixer dev: 0
Sample rate source: 0
Preferred channel configuration: Not indicated
Supported number of channels (min - max): 2 - 6
Native sample rates (min - max): 8000 - 48000
HW Type: Not indicated.
Minimum latency: Not indicated

VIA VT8235 (vmix) loopback record /dev/oss/oss_via823x0/loop0 (device index 1)
Legacy device NONE
Caps: DUPLEX BATCH TRIGGER MMAP MULTI VIRTUAL HIDDEN
Modes: IN/OUT
In engine 1: 5/VIA VT8235 (vmix) loopback record
Available for use
Engine 2: 6/VIA VT8235
Available for use
Formats: 0x10 in, 0x10 out
Device handle: PCI41611106-0000:00:11.5-au02
Related mixer dev: 0
Sample rate source: 5
Preferred channel configuration: Not indicated
Supported number of channels (min - max): 2 - 2
Native sample rates (min - max): 48000 - 48000
HW Type: Not indicated.
Minimum latency: Not indicated

IMux0 audio record /dev/oss/oss_imux0/pcmin0 (device index 2)
Legacy device /dev/dsp10
Caps: TRIGGER VIRTUAL
Modes: INPUT
In engine 1: 7/IMux0 audio record
Available for use
In engine 2: 8/IMux0 audio record
Available for use
Formats: 0x10 in, 0x10 out
Device handle: oss_imux0-au01
Related mixer dev: 1
Sample rate source: 0
Preferred channel configuration: Not indicated
Supported number of channels (min - max): 1 - 2
Native sample rates (min - max): 5000 - 192000
HW Type: Not indicated.
Minimum latency: Not indicated


Nodes
/dev/dsp -> /dev/oss/oss_via823x0/pcm0
/dev/dsp_in -> /dev/oss/oss_ich0/pcm0
/dev/dsp_out -> /dev/oss/oss_ich0/pcm0
/dev/dsp_ac3 -> /dev/oss/oss_ich0/pcm0
/dev/dsp_mmap -> /dev/oss/oss_ich0/pcm0
/dev/dsp_multich -> /dev/oss/oss_ich0/pcm0