Re: External PCM plugin SDK

[Marcel Holtmann <marcel@holtmann.org>]

Hi Takashi,

> > and I need full duplex IO and volume control inside the same plugin for
> > the headset/handsfree support.
> 
> Hmm, the share of volume control stuff between PCM and control plugins
> might be a bit tough.

the problem is that the headsets can report back volume changes. We will
see this for the high quality headphones also some day, because the
audio and video remote stuff for Bluetooth is already specified.

I will start without reacting to the volume control. We will see how
this works out.

> > > You don't have to set them if the hardware has no restriction.
> > > Usually, the period size defines the interrupt period.  In the case of
> > > user-space driver, it corresponds to the expected poll period, etc.
> > 
> > I can skip IOPLUG_HW_PERIOD_BYTES and IOPLUG_HW_PERIODS, but I must set
> > IOPLUG_HW_BUFFER_BYTES, because otherwise it segfaults even with aplay.
> 
> OK, then use snd_pcm_ioplug_set_param_minmax() with some sane values.

Leaving IOPLUG_HW_BUFFERS_BYTES out and only setting the period stuff
makes it working with the XMMS from CVS.

Problem now is that XMMS closes the device and re-opens it when changing
the track and even when switching to its next track. This is problematic
when using Bluetooth, because I need to keep the underlaying connection
alive. Any idea?

> > Let's take an unsigned long to handle more than 32 flags ;)
> 
> Well, I'd like to keep 32bit.
> 
> Nowadays no one knows whether the exported struct is shared between
> 32bit and 64bit environment.  Once if we have to implement a 32bit
> wrapper, the difference of long is simply a pain.

Fine with me.

Regards

Marcel




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click