Announcement

Collapse
No announcement yet.

ALSA's TinyCompress Audio Library Gets A Release

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • 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...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

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

    Comment


    • #3
      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.

      Comment


      • #4
        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.

        Comment


        • #5
          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

          Comment


          • #6
            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; 25 February 2013, 07:20 AM.

            Comment


            • #7
              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.

              Comment


              • #8
                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.

                Comment


                • #9
                  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)


                  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)

                  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.

                  Comment

                  Working...
                  X