Results 1 to 9 of 9

Thread: ALSA's TinyCompress Audio Library Gets A Release

  1. #1
    Join Date
    Jan 2007
    Posts
    14,373

    Default ALSA's TinyCompress Audio Library Gets A Release

    Phoronix: ALSA's TinyCompress Audio Library Gets A Release

    Today marks the first tagged release of TinyCompress, a user-space library that takes advantage of ALSA Compressed APIs that were recently introduced in the mainline Linux kernel. This library allows for feeding compressed data like MP3 files directly to ALSA compressed audio devices. This allows for offloading more of the audio playback process to supported audio hardware...

    http://www.phoronix.com/vr.php?view=MTMxMTQ

  2. #2
    Join Date
    Dec 2012
    Posts
    196

    Default

    I'm guessing that Gstreamer with an ALSA could take advantage of this, but not with Pulseaudio in between.

  3. #3
    Join Date
    Jun 2008
    Location
    Perth, Scotland
    Posts
    435

    Default

    Quote Originally Posted by newwen View Post
    I'm guessing that Gstreamer with an ALSA could take advantage of this, but not with Pulseaudio in between.
    I suspect that depends on whether hardware mixing is present. I'd be surprised if they have designed these chips so that using this feature blocks all other sounds. If hardware mixing is present, maybe PulseAudio could pass through such streams while continuing to use the card normally for other streams.

  4. #4
    Join Date
    Feb 2009
    Posts
    368

    Default

    I guess this would only be useful on mobile devices, right? Playing or making compressed audio on a desktop PC uses a negligeable amount of cpu power these days, unless one was doing some kind of production work.

  5. #5
    Join Date
    Mar 2011
    Posts
    90

    Default

    Quote Originally Posted by benmoran View Post
    I guess this would only be useful on mobile devices, right? Playing or making compressed audio on a desktop PC uses a negligeable amount of cpu power these days, unless one was doing some kind of production work.
    I do not know where guys like You for whom better use of the hardware is not important are coming from... Here is quote for You from the very article You comment on
    Processing compressed data on such DSPs results in a dramatic reduction of power consumption compared to host-based processing
    Now think of the of the number of devices that might be in use under Linux that this change might affect and let's say it saves only 1W for each the total amount of energy saved will be quite substantial at least IMHO

  6. #6
    Join Date
    Jul 2008
    Location
    Greece
    Posts
    3,779

    Default

    Quote Originally Posted by ryszardzonk View Post
    I do not know where guys like You for whom better use of the hardware is not important are coming from... Here is quote for You from the very article You comment on
    Now think of the of the number of devices that might be in use under Linux that this change might affect and let's say it saves only 1W for each the total amount of energy saved will be quite substantial at least IMHO
    How many PC sound cards do you know that offer DSP decoding? The ones that the vast majority of people have, some on-board codec, do not. Creative's cards: nope. That's already about 95% of people. Then we can check Asus and the rest: nope. No decoding either.

    It doesn't seem important at all on the PC. And I'd be surprised if decoding an MP3 stream even takes 1W on desktop CPUs.
    Last edited by RealNC; 02-25-2013 at 06:20 AM.

  7. #7
    Join Date
    Sep 2011
    Location
    Rio de Janeiro
    Posts
    201

    Default

    Quote Originally Posted by RealNC View Post
    How many PC sound cards do you know that offer DSP decoding? The ones that the vast majority of people have, some on-board codec, do not. Creative's cards: nope. That's already about 95% of people. Then we can check Asus and the rest: nope. No decoding either.

    It doesn't seem important at all on the PC. And I'd be surprised if decoding an MP3 stream even takes 1W on desktop CPUs.
    And the development should anly target present hardware right? I mean if Intel incorporates a DSP block into a broadwell SoC which will be used in a tablet/hybrid in 2014 then developers should start to consider developing for it, and maybe in 2016-17 we will have usable software.

    And the power figures might be much worse if all the CPU is doing is decoding sound. If the cpu can be kept asleep while deconding I would expect a very tangible power save.

  8. #8
    Join Date
    Sep 2011
    Posts
    40

    Default

    As of PulseAudio 1.0, we support passthrough output of compressed formats. This allows us to directly support passing compressed audio to hardware that supports it. Currently, the only hardware for which we support this is A/V receivers plugged in over S/PDIF or HDMI, but this can include hardware decoders on SoCs and streaming MP3/AAC/... to Bluetooth headsets that support it in the future.
    http://www.freedesktop.org/wiki/Soft...er/Passthrough

  9. #9
    Join Date
    Apr 2008
    Posts
    155

    Arrow

    Quote Originally Posted by benmoran View Post
    I guess this would only be useful on mobile devices, right? Playing or making compressed audio on a desktop PC uses a negligeable amount of cpu power these days, unless one was doing some kind of production work.
    On a desktop, dedicated hardware acceleration (for mixing and/or decompressing) DOES HAVE a use: lower latency.
    - Desktops might have more than enough processing power for mixing and decompressing.
    - Desktops might such a high power usage that dedicated hardware might not impact that much.
    BUT
    - Unless you use some type of optimized real-time kernel, due to audio-data processing and multitasking, you're always going to have some audio latency on a desktop.

    So support for hardware functions, can be useful for use cases where latency matters like :
    - Gaming (really matters a lot)
    - Communication (lower latency helps a lot, specially if decompression is hardware)
    - multimedia playback (can help a little bit playing synchronised video/audio with less latency).
    Of course it won't help for the most usual use-case and what sound daemon are mostly used for:
    - Playing system sounds.
    (99% of a desktop's uptime, the sound deamon either sit idle, or just plays the various system beeps)


    Quote Originally Posted by RealNC View Post
    How many PC sound cards do you know that offer DSP decoding? The ones that the vast majority of people have, some on-board codec, do not. Creative's cards: nope. That's already about 95% of people. Then we can check Asus and the rest: nope. No decoding either.
    some obscure old delta-based simple compression schemes have been supported since ages in lots of cards.

    Creative's cards DO HAVE hardware decompression support at least since the Audigy series of cards for AC3 and DTS streams.
    C-Media sound chipset even support hardware *compression* (as in: play regular 5.1 audio like a game, the card compresses it on the fly into a DTS stream to by carrier over a single digital connector to your living room's sound system).
    And technically, any card with a digital out could transmit compressed sounds as long as the decoder at the other side of the digital link supports the compression format. (as mentionned by pankkake)

    Until now, with ALSA, this required putting some special settings into sound mixer (in order to activate direct digital pass-through, set the correct IEC headers in the digital packets), and then sending the compressed data is if it were raw PCM data.
    And all these compression scheme have been CBR (constant bit rate any way) (easy to maskerade as raw PCM data).

    The present library adds an actual standard API to do that (instead of fumbling with mixer settings) and introduces support for VBR (Variable Bit Rate) as used on lot of small portable files (MP3, AAC, OGG, etc)

    Quote Originally Posted by newwen View Post
    I'm guessing that Gstreamer with an ALSA could take advantage of this, but not with Pulseaudio in between.
    As mentionned by pankkake, pulseaudio does support compressed audio.

    On the other hand, as far as I known pulse audio doesn't support hardware mixing.
    (So no easy way to send a compressed stream and systems sounds, or several system sounds, and have them processed by the hardware.
    Currently, it's either passing a single compressed stream to the output. Or sending a uncompressed stream of PCM which was processed on the main CPU).
    But I haven't read pulseaudio's source code, so maybe I am wrong.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •