On Wed, Oct 29, 2014 at 10:50:19AM +0800, Greg Kroah-Hartman wrote: > On Tue, Oct 28, 2014 at 03:05:16PM +0000, Qais Yousef wrote: > > On 10/28/2014 02:13 PM, Greg Kroah-Hartman wrote: > > >On Tue, Oct 28, 2014 at 01:18:28PM +0000, Qais Yousef wrote: > > >>On 10/28/2014 11:55 AM, Clemens Ladisch wrote: > > >>>Qais Yousef wrote: > > >>>>AXD Audio Processing IP performs audio decoding, encoding, mixing, equalisation, > > >>>>synchronisation and playback. > > >>>What exactly do you mean with "synchronisation" and "playback"? > > >>Synchronisation refers to accurate audio playout relative to a master > > >>clock source including compensation of drift between the master clock > > >>source and the playout clock of the audio hardware. Hence allowing > > >>synchronised audio playout across multiple independent devices. > > >> > > >>Playback simple refers to the fact that AXD is capable of managing audio > > >>playout hardware like I2S and SPDIF interfaces. > > >> > > >> > > >>>>It doesn't fit in alsa subsystem but I Cced them to confirm. > > >>>... because those two words sound like something that a sound card could do. > > >>The problem mainly stems from the fact that we take a variety of > > >>compressed audio as input and we could perform audio encoding. The > > >>problem with the compressed audio is that the range of decoders and > > >>configuration supported in alsa is limited and there's no support for > > >>taking raw pcm and producing compressed output. I'm not an expert on > > >>alsa but when I looked it looked like there's more infra structure > > >>required. > > >> > > >>The following not supported points from Documentation/sound/alsa/compress_offload.txt affect us: > > >> > > >>- Volume control/routing is not handled by this API. Devices exposing a > > >> compressed data interface will be considered as regular ALSA devices; > > >> volume changes and routing information will be provided with regular > > >> ALSA kcontrols. > > >> > > >>- Embedded audio effects. Such effects should be enabled in the same > > >> manner, no matter if the input was PCM or compressed. > > >> > > >>- Encoding/decoding acceleration is not supported as mentioned > > >> above. It is possible to route the output of a decoder to a capture > > >> stream, or even implement transcoding capabilities. This routing > > >> would be enabled with ALSA kcontrols. > > >So instead you created a one-off api just for this hardware? Ick, no, > > >please work with the audio developers to incorporate it into the > > >standard Linux audio apis so that everyone can benifit and not require > > >special userspace programs to drive this hardware. > > > > > >thanks, > > > > > >greg k-h > > > > OK. I'll wait to hear from alsa developers to see the extent of work > > required. I can't see it being trivial though. Would it be possible for this > > to be accepted into staging until this is resolved? > > If you are willing to abide by the staging rules: > - incremental patches only doing one thing at a time > - never break the build > - constantly moving forward to getting merged (i.e. no new > features being added) > > I think it will be easier for you to do the work outside of the tree as > you are going to be changing the API, which is not going to be easy to > do in an incremental patch series. > > And yes, this isn't going to be a trivial amount of work, sorry. I am not sure if it can fit into staging model. The whole design of driver would need rework and all the infrastructure added here for exposing stuff to usermode will be thrown away, so this driver would simply need an major overhaul. If this was ALSA driver and we would need to plumb it for acceptance then would have made sense in include, but thats not the fact today Thanks -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
