From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: External PCM plugin SDK Date: Wed, 09 Feb 2005 18:32:41 +0100 Message-ID: References: <1107958458.13863.43.camel@pegasus> <1107959869.13863.62.camel@pegasus> <1107970036.13863.77.camel@pegasus> Mime-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII In-Reply-To: <1107970036.13863.77.camel@pegasus> Sender: alsa-devel-admin@lists.sourceforge.net Errors-To: alsa-devel-admin@lists.sourceforge.net List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , List-Archive: To: Marcel Holtmann Cc: alsa-devel@lists.sourceforge.net List-Id: alsa-devel@alsa-project.org At Wed, 09 Feb 2005 18:27:16 +0100, Marcel Holtmann wrote: > > Hi Takashi, > > > > it is putting the PCM data into the SBC encoder and then sending it to > > > the RFCOMM socket. This is not the standard for high quality audio over > > > Bluetooth, but my Aiptek headphone supports this stuff. For now this is > > > easier than dealing with A2DP and AVDTP. > > > > > > The SCO support for the headsets is another story. > > > > ... and we'll need control plugin for mixers, too. > > 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 XMMS is version 1.2.10 and BMP is version 0.9.7. In what versions > > > are the ALSA plugins fixed. I will build it from source. > > > > The patch isn't in the released version. IIRC, they were applied to > > CVS, though. > > I checked the latest XMMS CVS and even it segfaults or I get an error: > > xmms: pcm_params.c:2294: sndrv_pcm_hw_params: Assertion `err >= 0' failed. > > Looks like a problem on my side. > > > > > Do you have buffer or period size constraints? > > > > > > Oh yes, that is the point where I am not sure what I am doing. The SBC > > > is a codec like MP3 and actually I have no idea what are the best values > > > here. These are software soundcards. > > > > 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. > > > > > We also talked about making these IO plugins visible when ALSA is > > > > > listing its hardware devices. Is this possible now? > > > > > > > > No, it's still in planning. > > > > We'll need to define a usable API first... > > > > > > What about a flags variable in snd_pcm_ioplug for activating it. This is > > > generic and for me this is enough, because both Bluetooth IO plugins are > > > virtual soundcards and they should always be listed. Or maybe list IO > > > plugins in general. > > > > This sounds good. I'll add like the following: > > 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. Takashi ------------------------------------------------------- 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