[Tutorial] tinycore OSS audio streaming

[hiro]

I've had my music server running on TC for quite some time now with mpd+OSS.
Next I wanted to listen to some of George Carlin's rantings. But since opera or even flash is too much for my tiny server I'm running all these web applications on my main laptop, which has no sound.
So I use ossrecord, netcat and ossplay to stream all the profanities over my wireless network.

Here's the server's part, it shall ouput your audio to it's soundcard:

Code: [Select]

#!/bin/sh
# listen on port 1234 with netcat, pipe what it gets to ossplay's stdin.
nc -l -p 1234| ossplay -
On your client, the sound source, you have to make OSS create a loop device.
In /usr/lib/oss/conf/osscore.conf set this option:

Code: [Select]

vmix_loopdevs=1Then, in order to hear that newest craze of flash adverts at 100db (or whatever you want to listen to) run this, also on the client:

Code: [Select]

#!/bin/sh
sudo soundoff
sudo soundon
ossrecord -s48000 -b16 -c2 -l -d /dev/oss/oss_hdaudio0/loop0 - | nc 192.168.178.23 1234
/dev/oss/oss_hdaudio0/loop0 is your loop device. For some reason binding to /dev/dsp only allows you to record from line/mic-in. So you have to use the loop device, which gets the full signal directly from your mixer (vmix). The samplerate of my mixer is set to 48kHz, 16bits, and of course 2 channels.
Sometimes restarting OSS is necessary for the loop plugin to work, so I include this in the script.

For this to work on tc you only need OSS.tcz. Here's the whole chain in two lines:

Code: [Select]

annoying flash banner -> OSS (vmix0.pcm -> vmix0-out -> loop0) -> ossrecord -> nc ip port->
soundcard <- OSS(vmix0-out <- vmix0.pcm) <- ossplay <- nc -l port <-


[tinypoodle]

Any chance there would be a way to achieve the same or at least similar with alsa?
It's exactly what I need and want since long, but alas, OSS doesn't like all soundcards which alsa does...  

[gerald_clark]

Have you tried using alsa-oss to provide OSS emulation under alsa?

[hiro]

I abandoned alsa because I couldn't find any documentation about stuff like that. Although I have to admit that I also had to poke around quite a bit to find out about needing to restart OSS.

I've heard that that there is a named pipe output in alsa. I never managed to set it up, but if you do you can cat|nc from that.

[tinypoodle]

First on your client, the sound source, you have to make OSS create a loop device.
In /usr/lib/oss/conf/osscore.conf set this option:

Code: [Select]

vmix_loopdevs=2

The more I try to understand what you did, the more confused I get...
"the sound source" would be the server, rather than the client, no?

And could you please clarify on which box you run the ossplay resp. ossrecord command, the box streamed from versus the box streamed to.

To me the way I understand it, it sounds somehow the wrong way round, but then I can't really understand what role the loop device plays.

[hiro]

No. The loop device has nothing to do with the streaming/networking. I've reordered my instructions to make this clear.

Audio sink and TCP/IP Server: nc -l 1234 |ossplay -
Audio source and TCP/IP Client: ossrecord|nc server

Sounds great here. Don't hesitate to ask questions if you don't understand me. Nothing here has anything to do with pulseaudio or black magic. It's all just pipes and sockets and perhaps a bit of greek mother tongue.

[tinypoodle]

I read the edited first post again (and again and again), and I simply don't get
1. which command is used on which box
2. what exactly the role and function of the loop device is

Do I get it right or not that ossplay is used on the box to be streamed from, while ossrecord is used on the box to be streamed to and sound to be heard on?
If so, then that would somehow go against my theoretical logics; but what matters is what practically has proven to work...

[hiro]

Do I get it right or not that ossplay is used on the box to be streamed from, while ossrecord is used on the box to be streamed to and sound to be heard on?

Nope, it's the other way round. Did I oversee anything?
Perhaps I shouldn't be allowed to use EDIT.

[tinypoodle]

Hmm, I had basically understood so even before your EDIT, I don't think that's at the core of my confusion, but obviously there is some miscommunication somewhere.

I'll try to describe how I understand whatever I do (correctly or not) and hope you could then confirm or correct me:
You refer to the server part which is followed by a command involving aplay.
Later you refer to the client, followed by a command involving arecord.

In my interpretation the server is the box where the sound originates from, e.g. a box where flashplayer would play in a browser well, but this box itself producing crappy or no sound.

The client would be the box where the sound output is desired to be redirected to, e.g. a box of generally lower specs but with a good soundcard and good speakers, producing desirable sound output.

Now in my personal simple linguistics and logics, lacking the full technical knowledge, I would imagine that the sound has to be recorded (e.g. ossrecord) on the box where e.g. the flashplayer is running, and to be played (e.g. ossplay) on the box where output of sound is desired. But the way I read all the instructions, it appears to me to be the other way round.

At least after your last editing I think to understand a tad more about the purpose of a loop device.

Sorry if I am persisting, but I actually had researched since long but casually about achieving this goal before you first posted about it, but then your post somehow inspired me to pursue this purpose with more intensity.

[hiro]

No, the server is what gets started when I run nc -l port.
You should read nc's manpage and perhaps http://en.wikipedia.org/wiki/Internet_socket#Socket_states_and_the_client-server_model

That's why I also brought in the source and sink model, so that you can see what is happening logically.

Your feeling was right. "Name ist Schall und Rauch." --Goethe

[hiro]

Sorry if I am persisting, but I actaually had researched since long but casually about achieving this goal before you first posted about it, but then your post somehow inspired me to pursue this purpose with more intensity.

I hope more people would ask such questions instead of creating monstrous bloat like pulseaudio.
So everyone feel free to ask...

[tinypoodle]

Thanks a lot for the wikipedia pointer, I think now to understand what your terminology is based on.

Remembering, first time I had read the manual of netcat several years ago, when some geek residing at the other end of the globe on IRC convinced me to participate in an experiment, netcat'ing a video file for me to watch in vlc.
Ever since, netcat had some touch of magical mystery to me, and I have occasionally read the manual again and googled for articles about.
Since you opened this thread, of course I have read the manual several times again.
My confusion resulted from the server/client terminology, which I had not taken notice before in relation to netcat.
What I would understand would be the "listen" and "connect" modes.
What I had understood that netcat in listen mode could amongst other obtain a stream.
Hearing about server/client, in my simple logics I associated "client" with the one "obtaining", e.g. running nc in listen mode.
Lacking of having achieved the very purpose discussed in this thread, I have used edna to at least being able to listen to mp3's on the box which has excellent sound but no persistent storage.
In that context, edna - running on the box where the mp3 files are stored - is definitely called a server and therefore I had the perception that the box where the sound originates from would be the server...

Semantics...  a bit of greek mothertongue and some Goethe quotes at times seem more human readable than technological terminology...

"Mit dem Wissen wächst der Zweifel" --Goethe

[hiro]

They should be teaching UNIX pipes and sockets in school. The concept is so easy, the possibilities nearly endless.

Often there are servers, which connect to other servers, which connect to file servers running on virtual servers, which then run on windows servers. Don't let it carry you away;)

edna's idea is also spot-on, and I think some day I might also try to do something like that (but without python). If only I had more time for actually building stuff...

[hiro]

What I had understood that netcat in listen mode could amongst other obtain a stream.

This is mixing up the terminology. A stream obviously has a direction. A socket (i.e. nc) not neccessarily.
Better just forget the word "stream" for the moment. It doesn't describe well what's going on technically.

[tinypoodle]

I might as well be one of your first customers, as I rarely would use python for any other purpose...

I was freely referring to the manual you had adviced me to read (and what I had absorbed and though t to understand about it)...

the listen mode can be used to obtain some kind of stream of data from a remote site