[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v5] sndif: add ABI for Para-virtual sound



On Thu, Jan 22, 2015 at 6:07 PM, Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx> wrote:
> Oleksandr Dmytryshyn writes ("Re: [PATCH v5] sndif: add ABI for Para-virtual 
> sound"):
>> On Thu, Jan 22, 2015 at 5:41 PM, Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx> 
>> wrote:
>> > So for example, much real hardware will have a headphone output and
>> > also built-in speakers, and a mic input and built-in microphone.
>>
>> > How is this to be exposed to the guest ?
>>
>> Every stream handled in the own thread in the frontend driver.
>> Frontend sends command (read or write, etc) to the backend and
>> this is blocking command (within current stream). So I just
>> use different streams for playback and capture.
>
> Right, I gathered that.
>
>> In case if we have
>> headphone output and also built-in speakers, and a mic input and
>> built-in microphone we will use one stream for the headphone output,
>> one stream for the built-in speakers and one stream for the mic input.
>> And in this time all devices will be able to work simultaneously.
>
> Perhaps I'm missing something but I don't see where the necessary
> information is passed in your protocol specification.
>
> Let us consider only output for now.  How does the guest choose which
> of the possibly-several output devices their stream goes to ?  Are
> these the multiple stream_id's ?  Are they identified solely by
> number ?  Is there a conventional mapping for these streams ?
For now we are using a simplified PV sound drivers.
Every streams can be opened for playback or capture.
And backend driver uses alsa and uses 'dmix' plugin for playback
and 'dsnoop' plugin for capture.
For now this protocol doesn't support mapping for streams and needs to be
reworked. I'll rework It in the next patch-set.
New nodes will be added to the xenstore with the stream mappings.
For now a single stream is virtualized but I think that whole sound card should
be virtualized by single frontend-backend connection. In this case we will be
able to pass the alsa device name (which is used by backend), virtual sound
card name and number, stream type (playback or capture) and stream number
for each stream inside the virtualized sound card.

Example of the configuration (which will be read from the xenstore):
Sound cart 'default', 'card number 2'
'mic' <-> 'captute', 'stream 5' -> /dev/snd/pcmC2D5c
'headphones' <-> 'playback', 'stream 3' -> /dev/snd/pcmC2D3p

Our backend uses ALSA and opens streams by name.

> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.