lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Wed, 29 Oct 2014 10:06:19 -0500
From:	Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>
To:	Qais Yousef <qais.yousef@...tec.com>,
	Clemens Ladisch <clemens@...isch.de>,
	linux-kernel@...r.kernel.org
CC:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	alsa-devel@...a-project.org, Neil Jones <neil.jones@...tec.com>,
	Arnd Bergmann <arnd@...db.de>, devicetree@...r.kernel.org
Subject: Re: [alsa-devel] [PATCH 00/11] Add AXD Audio Processing IP driver

On 10/28/14, 8:18 AM, 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.

Volume control, effects and routing aren't supported directly with the 
snd_pcm streaming interface either. we didn't add these features either 
in the compressed API since they could be enabled through existing means 
(kcontrols and routing).

>
>
>
>>> I added it to drivers/char as this is the best location I could think
>>> of at the
>>> moment.
>> drivers/misc?
>
> Yeah could do if there's consensus.
>
> Thanks,
> Qais
>
>>
>> Regards,
>> Clemens
>
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@...a-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ