Re: [alsa-devel] Information request - writing a driver for a virtual soundcard
(please never remove any people from the list of recipients when replying, and please do not top-post)
On Wed, Aug 18, 2010 at 09:27:36PM +0200, Olof wrote:
I want to connect my smartphone to my amplifier and then use it as a virtual soundcard. The actual sound data shall be transmitted over wireless TCP/IP from my laptop to the smartphone, enabling me to move around in the flat without wiring.
I still don't understand where the actual audio material has its origin, or where it should be sent to, respectively.
Thought a virtual soundcard was a good idea since it the whole system then would be independent of application playing sound on the laptop. I intended to do the compressing & transmission in user space, but perhaps everything can be done in user space? I wasn't aware of the possibility. Where can I read more?
I think the easiest API to access your existing sound cards and to create virtual sinks and sources is offered by PulseAudio:
http://pulseaudio.org/wiki/DeveloperDocumentation
In case your distribution uses PulseAudio natively, you souldn't even need to set up anything.
HTH, Daniel
I still don't understand where the actual audio material has its origin, or where it should be sent to, respectively.
Origin is anything the user would choose to play on a "normal" system. Pure sound from CD, mp3, ogg, wma played with xmmls, totem movie player etc. Any application used to play sound on a Linux box. The PCM stream would be compressed and transmitted over TCP/IP to the smartphone which would play it on its output.
Thanks, Olof
On Wed, Aug 18, 2010 at 09:44:05PM +0200, Olof wrote:
I still don't understand where the actual audio material has its origin, or where it should be sent to, respectively.
Origin is anything the user would choose to play on a "normal" system. Pure sound from CD, mp3, ogg, wma played with xmmls, totem movie player etc. Any application used to play sound on a Linux box. The PCM stream would be compressed and transmitted over TCP/IP to the smartphone which would play it on its output.
Jup. You can easily do that by capturing the PulseAudio master monitor and do whatever you like with the data inside your PulseAudio client.
Another option - in case you have full control over the code running on the smart phone - is to make the phone act as PulseAudio network service, so multiple other network members could send audio to it, or receive audio from it. With or without authentication, compressed or uncompressed and all that, depending on your implementation.
Daniel
participants (2)
-
Daniel Mack -
Olof