Bug 57503 - Playing audio with smart resampling
Summary: Playing audio with smart resampling
Status: RESOLVED FIXED
Alias: None
Product: PulseAudio
Classification: Unclassified
Component: daemon (show other bugs)
Version: unspecified
Hardware: All All
: low enhancement
Assignee: pulseaudio-bugs
QA Contact: pulseaudio-bugs
URL:
Whiteboard:
Keywords:
: 100283 (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-11-25 09:49 UTC by Stéphane
Modified: 2017-03-20 07:26 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Stéphane 2012-11-25 09:49:07 UTC
Hello,

It's not really a bug I'm describbing, but a feature.

By default, pulseaudio is resampling all audio streams to 16bit 44.1 Khz format, if set so.

It would be much better if pulseaudio smartly choose the best resampling format, while analysing what client is playing.

There should be maybe 3 or 4 level :

 First   : - All audio players (Amarok, Clementine, Listen, Rhythmbox,...)

 Second  : - Video players (VLC, Dragon PLayer, mplayer ...)
           - Games

 Third   : - System sounds
           - Flash plugin
           - All other sound clients ....


When you are playing an audio file (and more if it is a lossless audio file), you expect this file to be played in his native format, without any compression or resampling process.

If this file is 24b-192KHz, then pulseaudio should dynamically switch to this format, and all other sounds (system, video, ...) should be resampled to this format too.
If this file is a 16b-44.1KHz, it should be played so, even if a video playing at the same moment is using a better format... (the sound from the video should be then resampled to 16b-44.1KHz.

If nothing is played but system sounds, then those system sounds should be played in the system sound native format...

All is finally sorted by priority.


Actually, If I want to play my files (most flac, but I have variety of them from 16b 44.1KHz to 24b-192KHz) in the native format, I need to uninstall pulseaudio. But doing so, I can't play sounds from more than 1 source anymore.

Please, make pulseaudio even more smart.

Thank you.
Comment 1 Stéphane 2013-06-04 18:30:49 UTC
Mmm, pulseaudio 4 is out, so I checked here to see if something has been done about the smart resampling idea.

Am I wrong, or nobody seems to care about audio quality ?

For an audiophile linux user, there is just one choice to play the original audio file : Bypass Pulseaudio.
Doing so, there is no way to play anything else at the same time. That's why we would really enjoy this smart resampling option in pulseaudio.

Thank you again.
Comment 2 Tanu Kaskinen 2013-06-05 08:19:23 UTC
This is not a high priority feature at least in my opinion, so getting this implemented any time soon probably requires someone outside the core development team to write a patch.
Comment 3 Stéphane 2016-03-16 12:59:10 UTC
Hello,

I'm here again, always needing this feature :)

I really can't understand why such an idea or something equivalent has not been implemented.
Pulseaudio actually has a default sample-rate and an alternative sample-rate, and I don't really understand when it use one or the other.

But really... wouldn't it just be much more smart and easy to make pulseaudio working in the native sample-rate of the stream having priority ?

As I mentioned, the priority level of each app could be set by user (in pulseaudio config files, or in app if available). A default "values set" might be proposed as well.

For those who wanted good sound, the only way was to remove Pulseaudio to work with alsa drivers directly.
But pulseaudio has now become a standard, almost all apps need it for the sound. So removing it from the system risks to break many apps smooth running. This is a really bad new for audiophile users, who are now trapped.

Unfortunately, I'm not developer, but I really think that this feature is easy to implement. It doesn't change much in Pulseaudio mode of operation, but it does change everything for sound quality and audiophile users.

Hoping to hear from an interested developer, thank you all for your attention.
Comment 4 Stéphane 2016-05-05 08:27:58 UTC
I'm here again.

I and audiophile users still need this "Smart Pulseaudio". There are so many users in forums looking for a way to remove pulseaudio, or disable it, because they can't meet their sound quality requirements.

I'm myself using DeadBeef at the moment, as this player allow to select Alsa instead of pulseaudio output, and the music is much better.

Pulseaudio are working great to make pulseaudio more simple, more integrated in the system.
Good ! But they should still have in mind, that more than a technical tool, pulseaudio is manipulating sounds (ok), but Music as well (Music is a art, feelings transmission is the most important thing that pulseaudio should care when a Music is played).


When I see the great work the developers did (eg pulseaudio working better with Jack server), I'm quite sure, that implementing a dynamic sample-rate mechanism according to an application sound priority would not be so difficult, and the benefits would be enormous for users who care !

And that would probably catapult pulseaudio to "Best Sound Server Ever" !

Thank you again to reconsider this proposal.
Comment 5 Arun Raghavan 2016-05-05 09:51:04 UTC
Personally, this is something I am looking to implement at some point. Unfortunately, there are a number of other things on my plate as well, so no promises as to when it'll get done.
Comment 6 Stéphane 2016-05-05 17:45:33 UTC
@Arun

Oh my god ! That's a cool answer ! :)

I'm not asking for promises, and I'm not requiring that smart mechanism to be implemented in the next 2 weeks :)

Your feedback itself is reassuring me about the idea. After 4 years (I opened this bug report in 2012), nobody seemed to find the idea interesting, at least it was far from being a priority ! What a shame ! What could be more important than sound quality in a sound server ?

So, today the problem with pulseaudio is not resolved, but I now see it with more optimism :).
Comment 7 Arun Raghavan 2017-01-28 08:00:07 UTC
I've posted a patch to possibly address this at:

  https://lists.freedesktop.org/archives/pulseaudio-discuss/2017-January/027409.html
Comment 8 Stéphane 2017-01-28 08:38:15 UTC
@Arun

I'm really pleased to see that you really implemented this option. Thank you.

How does it work now with this commit to be added? Does it need to be agreed by a community ? Is it supposed to be integrated in the next release of Pulseaudio ?

really exciting evolution of pulseaudio, Thank you again.
Comment 9 Arun Raghavan 2017-01-30 08:40:46 UTC
Fixed with the following commit:

commit cc021c73305023a113f78190fb1b995528d003ae
Author: Arun Raghavan <arun@arunraghavan.net>
Date:   Sat Jan 28 13:19:08 2017 +0530

    sink, source: Add a mode to avoid resampling if possible
    
    This adds an "avoid-resampling" option to daemon.conf that makes the
    daemon try to use the stream sample rate if possible (the device needs
    to support it, which currently only ALSA does), and there should not be
    any other stream connected).
    
    This should enable some of the "audiophile" use-cases where users wish
    to play high sample rate audio files without resampling.
    
    We still will do conversion if sample formats don't match, though. This
    means that if you want to play 96 kHz/24 bit audio without any
    modification the default format will need to be set to be 24-bit as
    well. This will force all streams to be upconverted, which, other than
    the wasted resources, should be relatively harmless.
Comment 10 Arun Raghavan 2017-01-30 12:32:32 UTC
(In reply to Stéphane from comment #8)

It will be in PulseAudio 11.0. You will need to add avoid-resampling = true to /etc/pulse/daemon.conf (you can just make a copy in ~/.config/pulse).

As I said on the mailing list, please do make sure you understand the likely real impact of this well -- http://people.xiph.org/~xiphmont/demo/neil-young.html
Comment 11 Arun Raghavan 2017-03-20 07:26:34 UTC
*** Bug 100283 has been marked as a duplicate of this bug. ***


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.