Clementine 1.3: no more alsa output card options?

[ghost]

Hello,

with the new Clementine v1.3 , I sadly discovered that we are not able to configure ALSA output card parameters anymore. I fortunately own an audiophile DAC and I used to output streams to "hw:2,0" to avoid resampling. Now this option is gone, while two new options are added ("Sample Rate" and "Minimal Buffer fill"). To me this is a regression. Before it worked well, now high resolution files are downsampled in any case, sounding worse than 44.1KHz ones. This is a pity, since Clementine is by far the best Linux audio player.

Kind Regards Alex

[hatstand]

I don't think we care about "audiophile" things.

[Ferroin]

I don't think he's going to be back as a user...

I'd give you 10 to 1 odds that what he means by 'audiophile DAC' is 'high-end sound card that can natively do 24-bit at 196KHz audio'

I assume the argument for removing this functionality was so that people didn't get confused by it, which is funny because the current functionality is almost as confusing. In the 'Output device' selection on my laptop, i get two options for Pulseaudio sinks (I need to just get rid of the simultaneous output device...), and 5 that appear to be intended as GStreamer internal device aliases (one each for ALSA, OSS, JACK, Pulse, and generic IPC).

[hatstand]

I'd be happy if we just removed all of it tbh and just used pulseaudio with no options.

[Ferroin]

We'd lose a lot more users if we went that way. To be entirely honest, the only reason I use Pulse audio at all is because there's software that I actually need on occasion for audio work that only supports Pulse (and because Chrome appears to refuse to work with anything else), if it weren't for that, I'd have ripped it out of my system long ago (or more likely never installed it) and switched to using JACK.

Clementine is a music player, which means that to a certain extent, we have to care about people who care about audio quality, and PulseAudio just falls flat on it's face in some cases there (and some of the design choices that they're discussing upstream are positively terrifying, I've heard rumors that they're thinking about routing sound over DBus, which is going to be horrible for latency, even if kdbus ever makes into mainline Linux).

[Ferroin]

I should also qualify my previous comment with the statement that I don't use 196k audio, I just stick to 48k because I can't discern any difference beyond that (and this is coming from someone who can often discern some codec parameters for lossy audio compression just by listening to the audio itself), but I care enough that I avoid Pulse for multimedia work if at all possible, going either straight to hardware if possible, and through JACK if not.

[hatstand]

http://www.aes.org/e-lib/browse.cfm?elib=5539

Examination of published blind listening tests reveal that listeners are strongly disposed to report differences in sound quality when given two alternatives that are identical. The tendency was found in every published test over the past 15 years where analysis was possible and ignorance of the effect caused some tests to be improperly designed or analyzed. The author conducted an extensive single blind listening response bias and it's relationship to order of presentation, listener expectations and the presence of loudness differentials. The findings lead directly to suggestions for consumer purchase behavior and scientific listening test design and analysis.

Not inclined to care :-)

[Ferroin]

And that is exactly why you use real double blind tests. Assuming that people really can't tell the difference, they'll guess wrong on average 50% of the time.

Now, with respect to pulse, I'm not talking about stuff like dithering and quantization issues as much as latency. If your audio pipeline stalls whenever you're doing computationally intensive DSP work on it while you're trying to do real-time work, it's a quality issue in the audio pipeline. I see this type of thing exponentially more often with Pulseaudio than with JACK or direct through ALSA. Hell, I even sometimes get things like this happening when I'm just listening to music with Clementine over Pulseaudio and am building some big software package at the same time.

[hatstand]

Buffer under-runs are an actual reason to change things.

[ghost]

it's not very cool to buy high resolution tracks and have them downsampled by whatever resampler (for ex. crappy default pulseaudio speex-floating-1), lowering quality, adding latency, overloading cpu, while having a 300€ DAC supporting files up to 192KHz. Before it worked like a charm while there will be more and more people buying "HD" tracks.

[ghost]

(surely this problem should be resolved by pulseaudio upstream too, agreed)

[hatstand]

http://www.aes.org/e-lib/browse.cfm?elib=13185

To study the difference of hearing impression among several high sampling digital recording formats, we conducted subjective evaluation tests of perceptual discrimination among following digital recording formats: 48kHz 24bit PCM, 192kHz 24bit PCM and DSD. Sound stimuli for the evaluation were originally recorded to maintain the exact same quality of analog input feeds to the three A/D conversion systems. The sound reproduction system for the subjective evaluation tests was also carefully designed to reproduce the original quality of each digital recording format. Listening panels were selected from students and faculty stuffs of university of music, recording engineers, and musicians. A pair test method was applied to the subjective evaluation. Through the several evaluation tests, no significant difference was observed.

[ghost]

-> among following digital recording formats: 48kHz/24bit PCM, 192kHz 24bit PCM and DSD <--

these are HQ streams. Nothing to do with 16bit/44.1KHz against 24bit/88.2KHz where qualitative difference is easely audible. Sorry.

[Ferroin]

24 versus 16 bit audio doesn't make as much difference as you think either... And easily audible for you doesn't mean it is for everyone either. For example, if you give me the same audio encoded in a 128kbps MP3 file and a FLAC file, same sample rate, same bit-depth, I can roughly 80% of the time identify which one is the MP3 just by listening to them both, yet I know numerous people who claim they can tell the difference between 44.1k and 192k sample rates who can't do the same better than about 50% of the time (which pretty much means they're guessing).

It's like the difference between using 24-bit color and 48-bit color in image work, there's minute differences, but better than 95% of humans can't tell the difference.

Even people who work for Xiph.org have written articles on this: http://xiph.org/~xiphmont/demo/neil-young.html

Now, on the other hand, avoiding the dithering and quantization issues is a practical reason to want to avoid Pulse (especially because a lot of high-end audio cards do up-sample to their native sample rate and format before doing any internal processing).

[ghost]

24bit is a great improvement for music with great dynamics and, above all, it highers the sound/noise ratio by almost 50dB.

I agree that a sample rate beyond 88.2 is pure commercial stuff, and that a listener need a high freq tweeter (as I do) and a newborn earing sensibility to enjoy it. That said, higher resolution helps reduce aliasing and other kind of distortion, that means, purer audio playback.

It is true that the listener should have a trained ear. Today's radio/streaming compressed dynamics and lossy formats music don't help, as crappy pc speaker and similar paraphernalia. You just have to get used, trained to enjoy the improvements.

But the loss of hw: alsa output means high res files that sounds worse than CD quality ones and higher resources used.

[Ferroin]

The problem with music that has such a high dynamic range is that you need an almost silent room to listen to it and get the whole range, which is not a luxury almost anyone has. As far as the SNR, if that's an issue, you should be getting better quality audio hardware so that you don't have to deal with the noise, as once the signal is analogue, the bit depth is irrelevant to the SNR, and most of your noise will be introduced on the analogue side of things.

As far as the sample rate, anything over 48k is pointless for regular distribution, because even that is above the nyquist limit for human hearing for more than 95% of the population, and if you're using good audio hardware at 48k, you should observe zero aliasing for any frequency below 16KHz (which is a reasonable upper bound on the frequency of most audio recordings), and almost none up to 24KHz (and if you actually have audio files that include anything higher than 20KHz, you're deluding yourself in other ways).

DRC on the radio and streaming is a necessary evil, for exactly the same reasons that having a high dynamic range in audio is an issue. To a certain extent, the lossy encoding is too (try streaming FLAC encoded audio over a 3G cell network with spotty coverage in a moving vehicle, and it will become a lot more apparent why), although a lot of sites take that way further than they need to (I regularly cringe when I see someone streaming audio from Youtube or a similar site), but neither of those points is particularly relevant to your primary complaint.

The only truly valid complaint as far as audio software is concerned is the bit about down-sampling done by PulseAudio (supposedly there's a configuration option to set the default format, but I've yet to see it actually work, and it ends up eating even more CPU time), and the complaint about higher resource usage (and I'm less sympathetic about this, if you're doing high quality audio or video, or even graphics work, you will use more resources, period).

[stockphrase]

I agree with the OP. One central reason I use Clementine is that I can use the ALSA audio sink and bypass Pulseaudio. It was a great feature, and one that set Clementine apart from other players.

[thomaspierson]

I maintain Clementine in Debian and they are users there which care about this feature too:

• https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=823301

A good reported use case is:

I have multiple sound cards in my box, and I put Clementine on a different one than everything else. Ie, non-default. I guess this is not an obscure scenario, as it's natural to put music to the room while keeping all random sounds to headphones.

And I'm not sure that we can do something like this only with pulseaudio configs.

Could you consider reopen this issue?

[kilobyte]

As for leaving pulseaudio the only option:

I for one don't have a high- or mid-end sound card, and don't make a claim of being an audiophile, but on my box pulseaudio makes a quite quiet yet well-audible annoying noise all the time, even when no sound is being played. That noise is absent on ALSA.

Another pulseaudio bug on the same machine: after resume from suspend, all sound is high-pitched and clipped until "killall pulseaudio" (it automatically restarts after a kill or crash). The only response I got upon reporting this was "your sound card doesn't support suspend". Which is provably false, as 1. this happens even when no sound was playing at the time of suspend, 2. no such problems with ALSA even if sound was playing (and pulseaudio uses ALSA for directly interacting with hardware).

So it's not only audiophiles for whom pulseaudio isn't adequate.

[Ferroin]

I think I may have said this in another issue relating to this, but this is something that could easily be hidden behind an 'Advanced output options' checkbox, thus eliminating any confusion for 'normal' users.

I still contend that the current design is just as confusing if not more so (most multimedia applications have options laid out nearly identically to how Clementine had them).

@thomaspierson It is actually possible to do that with Pulse, it's just a serious pain (and this is coming from someone who's built Linux systems from scratch without using tools like buildroot). You functionally end up having to run multiple instances of Pulse with different configs and use some trickery with cgroups to keep them from trying to access certain sound cards, and then force routing for specific applications to the appropriate sound server.

So, in other words, not having this functionality in Clementine prevents 'normal' users from using it in a perfectly reasonable way without doing things which are even more likely to confuse them and potentially risk breaking their system completely.

[Ferroin]

OK, this advice won't fix the routing issues (which IMHO are the bigger issue here), but I've got a list of what PA settings to change to get better quality.

All of these are found in the Pulseaudio daemon configuration file. On Gentoo systems this is /etc/pulse/daemon.conf, but it may be somewhere else on other distros. For more specific info on the settings, check man pulse-daemon.conf.

1. resample-method: This specifies what algorithm pulse uses to resample audio streams. The upstream default is speex-float-1, which provides somewhat poor quality, but is insanely fast. The three possibilities for high quality re-sampling are:
   • soxr-vhq: This uses the same resampling as SoX. It's the highest quality and (usually) lowest CPU option, but introduces a pretty significant delay in the audio pipeline. Your version of pulse may or may not support this (you may need to install libsoxr).
   • speex-float-10: This is the high quality version of the default resample method. It's reasonably fast with much better quality, and produces the least latency of the three resamplers I'm listing here. It's also always included in pulse (I'm pretty sure, I've not seen a switch to turn off support during the build).
   • src-sinc-best-quality: This uses libsamplerate to do the resampling, using it's highest quality algorithm. It has very well characterized behavior (97dB SNR, 97% bandwidth preservation), and runs reasonably fast. This is what I personally use on my system now as I can hear no audible difference from soxr-vhq other than the reduced latency.
2. default-sample-format: This specifies the default sample format. With limited exceptions, this is the sample format that Pulseaudio's drivers try to use to open an audio device. The default is s16ne, which is signed 16-bit samples matching the bit-order of the CPU. For signed 24-bit samples, you want s24ne. There are a bunch of other settings (including 32-bit float and integer formats), but s24ne and s16ne are generally the only two that are relatively guaranteed to work on any given hardware.
3. default-sample-rate: This one is pretty self-explanatory. The default is 44100. Supported frequencies depend on both your hardware and the driver code (on my laptop with an Intel HDA chip with a Realtek codec, I've tested the following to work: 22050 44100 48000 96000, and the following don't work 88200 192000).
4. alternate-sample-rate: This specifies an alternative sample rate to try before changing other parameters. By default, the default-* parameters are used on the first attempt to open a device, then various parameters are adjusted down in quality until something is found that works. Setting this overrides that behavior to first try a different sample rate before adjusting anything else. This is unset by default.

[tari01]

Until recently I was able to circumvent this regression in 1.3.1 by manually editing .config/Clementine/Clementine.conf and editing these lines:

[GstEngine] sink=alsasink device="hw:0,3"

(where 3 was the SPDIF in my case)

The other day there was an update to 1.3.1-228 and since then all my 192Khz is being sent out as 96Khz. All other rates are untouched, i.e. 44100, 48000, 88200 and 96000 reach the receiver "unharmed". Using pulse is not really an option due to the large variety of samplerates my files have, so there would be a lot of really unnecessary up- and downsampling whenever the player moves to a new file.

Anyone with a similar issue, or any thoughts?

[samthiriot]

I don't think we care about "audiophile" things.

Somewhat surprising to read this and the following discussion. Sounds to me like reading on a Gimp bugtracker "I don't think we care about graphist designers things". And reading then a debate that explains how color spaces are not perceived by 99% of the population. And that you can tweak things around to still have decent results. Well, graphic designers still do care, independently of your own assessment. Sure they can use another famous commercial product. But why removing a feature they liked ?

Some users do care. Some users invest in good quality sound cards that are able to read files with no resampling. Some users do download flac files for lossless. Some download highquality sound files. Some others invest in DAC that have the same capability. Some people do invest thousands in their sound system and trust the quality of the sound source does matter. Some people trust that resampling leads to losses - wait, isnt that sampling theory ? It's not my role to judge whether they are right or wrong - it is yours ?

What is the next step in this case ? Why even offering the option to display the bitrate and bandwidth in Clementine ? There are concluding studies that show mp3 with right parameters lead to no perceiveable loss - them remove support for flac, what for ?

To conclude: Clemetine was a great player that I recommended to lots of people. Thanks for maintaining it ! I'll probably reuse it if you do care about sound quality.

[Ferroin]

Yeah, the whole thing did get rather off track.

TBH, the thing that bugs me the most about this is that the default for this option worked for 99% of people. That means that only 1% of users ever had to touch it. Such an option is something that would be perfectly fine to hide in the config file or in some 'Advanced' section in the regular UI, but instead of trying to find a way to make it so that it wouldn't confuse regular users while still being usable, the devs decided to change it in a way that actually makes it more confusing for the people who used it in the first place. Based on looking at it further, it should be possible to set it to output via ALSA, then use the regular ALSAlib environment variables to specify what device to use, but that's insanely more complicated to set up and beyond that, to change, and IMNSHO, it's just as confusing as is for normal users who don't need it.

[Sal1950]

As a long time Clementine user and retired QC member of the PCLinuxOS dev team I would just like to add my request for continued support of "audiophile" things. My current desktop PCLOS built has Clementine and it's gstreamer requires pined to the 1.2.3 version. My music library contains many files of all the different bitrates up to 24/192. The ability to route that stream directly to my outboard premium USB DAC is very important to me as it is to all of my friends who are concerned enough about sound quality to make sizable $ investments in reproduction gear and HDA music files. I've distributed my custom OS version with the pined Clementine to a number of other users now to whom sound quality was more important than any features of the latest builds. The number of quality conscious Clementine users is larger than you might think. A reconsideration to returning these features would be greatly appreciated by many. Thanks, Sal

[kilobyte]

@Sal1950: why exactly would you want to listen to media at 24/192? You can't tell the difference after 16/44 in any real world setup: 16-vs-24 bit can in theory be told apart in a specially quiet room, with volume set near the pain threshold, on very quiet (lowest bits) samples, and even that only if the 16 bit file was truncated rather than dithered. 44KHz can't be told from anything higher, period, unless someone made a dumb mistake (like naive resampling). That "sizable $ investment in reproduction gear"? You got scammed, sorry. Higher sample sizes and resolutions are useful only if that audio is used for further processing, but Clementine is pretty useless for that. Higher sampling rate being undistinguishable for human ear is like global warming or tobacco causing cancer: despite the science being thoroughly settled, there's money in claiming otherwise.

You can often find 24/192 media that indeed sounds better than what the company sells at 16/44, but the secret is: these are not really the same. The version for "normals" is serfed (I won't grace them by using the word "mastered") with less than 4 bits of dynamic range because it appears to sound better when placed next to non-cheating competition; it takes countermeasures like ReplayGain to defeat such tricks. But if you take that "audiophile" 24/192 file, sanely downsample it to 16/44 (this is easy to get wrong!), you won't be able to ABX them apart. And if you can't ABX, all you paid for is placebo.

This said, PulseAudio doesn't work for everyone, and is rife with bugs (like those two I described above), so being able to configure non-PulseAudio sinks is important, no matter whether someone's reasons for such configuration are sound or not.

[Sal1950]

I see no reason to debate the value and audibility of HDA (High Definition Audio) files here, that is better left elsewhere. I would point out the large market for a media player capable of handling these files and providing the best possible sound quality playback. Higher sampling rate music files are the future of media delivery is the bottom line here. The labels are going to sell product on the "more is better" claim, whatever the truth. Witness the recent development of players such as HQPlayer, JRiver, Audivarna, Amarra, Roon, etc. Clementine will surely lose the users that are quality conscious to these others if they can't offer a few of the basic features needed. I've been active in the open source community for many years now and it would be wonderful to have a high fidelity option to the Linux users. Let's work together for a better, more versatile Clementine, whatever our personal reasons or goals.

[Ferroin]

@kilobyte Had you considered that the output may be going to other audio processing equipment? In that case, you want to match the input rate it expects, and have the highest quality possible. On top of that, many people actually can tell the difference when dealing with low quality encoding algorithms (a minimal quality MP3 will sound noticeably different to many people at 24/96k versus 16/44.1k). What people can differentiate may surprise you. I can more than 80% of the time differentiate between FLAC and 320VBR MP3 with identical sampling derived from an original uncompressed copy, and can hear enough of the encoding artifacts in standard quality MP3 and similar codecs that I often cringe when I hear someone playing music off of YouTube.

24/192 audio is a bit like a HDR image. There are numerous valid uses for both, but home audio/home pictures are not one of them. That said, there's nothing that says that Clementine is only for home audio usage. I know at least 3 professional DJ's who used to use it before the audio routing abilities were neutered, and have used it myself for similar things.

[Sal1950]

Another request to please consider returning this function to Clementine. The MQA juggernaut continues to sign up all the major recording labels and streaming/downloading sources to deliver high bit rate audio (HDA) to consumers. MQA is a new form of data compression that will allow 24?192 rates to be delivered in CD sized files.. The marketing for it has already become the big buzz in music delivery and will soon be a driving force in customer demand. For Clementine to be a compatible media server it will need to be able to deliver this data stream to the new MQA outboard DAC's that are right now on the market. The future of music delivery is HDA http://www.cepro.com/article/mqa_continues_to_gain_momentum_with_audio_companies_record_labels http://www.mqa.co.uk/ Thanks again for your consideration.

[Sal1950]

Sadly have had to add this CON to the Best Linux Music Servers list. https://www.slant.co/topics/2016/viewpoints/5/~music-players-for-linux~clementine

"Bit perfect output no longer configurable Sadly after v 1.2.3 the output configuration to obtain bit perfect stream was removed. Plea's to the dev's have been answered with "I don't think we care about "audiophile" things." :( https://github.com/clementine-player/Clementine/issues/5344"

[jkorten]

Use gmusicbrowser instead. Supports bitperfect using alsa and much better performance for large databases. Too bad they broke clementine.

J

[jkorten]

Ferroin you dont have good hearing which does not mean others dont too

[Ferroin]

@jkorten If you pay attention, I actually admit to this, and on top of that defend specific parts of both sides of the argument here over HQ audio. To summarize my points:

• Codec has much more impact than people give it credit for, and MP3 as it's used by most people is crap. A switch to FLAC or another lossless codec as the standard for internet usage would actually have a vastly greater impact on the audio quality of end users than ramping up the sample size and sample rate does.
• 24-bit audio has limited utility for actual listening for most people. Average human hearing is closer to 20-bit in terms of what it can discern in most listening conditions. 20-bit is of course insane to work with for multiple reasons (both hardware and software), so 24-bit equipment and encoding is still useful. This falls into the same category as HDR images though. 24-bit color isn't quite the same size of gamut as human vision, but 48-bit is way beyond what humans can actually perceive.
• Increasing the sample rate increases the impact of noise, because you have more instances where noise can have an impact (twice as many samples means twice as many chances for noise to creep in). This in turn means that increasing your sample rate can decrease the SNR of the reconstructed signal (and quite often does because higher frequency DAC operation is more environmentally sensitive).
• 48k audio is mathematically sufficient for almost any audio recording. Application of simple signal theory combined with typical audio signals (specifically instrumental and vocal signals) and generally accepted models of human hearing means that 48k will give no discernible aliasing for normally used frequencies for more than 95% of people. Given a good dithering algorithm, it functionally gives zero aliasing for all signals up to 8kHz, with near zero up to 16kHz, and minimal up to 24kHz. The upper limit of human hearing is 20kHz, and most audio you're realistically going to be listening to doesn't peak over about 6-10kHz.
• For certain types of audio, 88.2k and 96k are reasonable. This really depends on the waveform's shape and a bunch of other factors. In most cases though, in a real double blind test, better than 95% of people can't actually distinguish between 48k and 96k even for audio recordings where it should make a difference.
• 192k is overkill for pretty much anything except scientific work. 192k sample can reconstruct anything up to 48kHz reasonably well, which is more than twice the maximal frequency for human hearing for more than 99% of the population and well above the upper end for the remaining 1%. That difference is actually a bad thing though, because anything recorded in that range has the chance to induce lower frequency harmonics, and you thus need more complicated hardware on the analogue side to avoid such issues.

Are there valid uses for 24-bit 192k audio? Yes. Is home audio one of them for most of the world's population? No. Is usage of a lossy codec valid for any of those uses for 24/192k audio? Absolutely not.

To summarize: people are focusing on the wrong things. We use MP3 and other such lossy formats because of bandwidth constraints which don't exist to anywhere near the same degree anymore. A 24-bit 192K 128kbps MP3 stream is roughly the same size as a 16-bit 48k FLAC stream, but the FLAC stream is technically higher quality audio because it's a lossless codec, whereas the MP3 is very lossy at 128kbps.

To reiterate my views on this whole issue in Clementine:

• I don't care that it doesn't support any arbitrary combination of sample size and sample rate. That's beyond what the scope of this discussion should have been.
• I do care that it can't route audio to an arbitrary output device anymore without jumping through hoops in ways that no regular end user should have to.
• I somewhat care that it by default can't give accurate reproduction of audio signals to the degree promised by the audio format. This is just as much an issue of Pulse itself having poor default quality and not offering decent options for flexibility in this area.

[jkorten]

Ferroin - you are not understanding the point of high sample rates in audio. We do not pass a 192kHz signal through a DAC to hear 96kHz sound. In fact most of the signal is low pass filtered out by somewhere between 30 and 50kHz. The point is that the filters used to band limit to 19kHz cause audible (and visible) ringing on the signal. This ringing causes beat-like interference with overtones and harmonics of music signals. (I actually have pix of this on another computer and will attempt to post.) OF COURSE you will pass more noise if it is there, but you pass signal as well. Not sure what kind of argument this is. Some of the best sound you will hear is on vinyl where there is plenty of noise, this does not interfere with the hi fidelity listening experience. Your evidently not qualified to discuss this issue from a technical standpoint.

-Your conclusion is clear though - you are not interested in having Clementine be used by audiophiles. -You think the people who care, and who manage to select alsa sink, and hw:x are being pushed beyond their capacity - we're lucky to have you babysit us. -You are mistaken if you think audiophiles are using pulse to transmit data to the DAC.

So please help me with my ignorance - are you the (a) developer of Clementine?

Oh - and for the record - if you can't hear the difference between 96K and 192K sample rates when played back on a DAC that can resolve both of them, then you are the one with a hearing issue - not 95% of the other people. It is plain as day to hear the difference. But don't sweat it - if you don't hear it, just don't deal with it. Those of us who do, want it. That's simple. I'm color blind - do I insist that there's no difference in mixing green and brown socks in pairs? WTF?

Jerry

[jkorten]

Here are pictoral examples of a 2.5kHz square wave sampled by a top tier professional audio analog to digital converter (Mytek 192 ADC) and played back on a Myteck 192 DAC - picture one is sampled and played back at 44.1kHz, picture two sampled at 192kHz. In addition - just so everybody understands how detrimental 44.1kHz is the last file is a playback capture of a 10kHz square wave at 44.1kHz.

Note the cursors in the first picture show the ringing occurs right where the steep cutoff (nyquist) filter occurs.

[kilobyte]

@korten: " if you can't hear the difference between 96K and 192K sample rates when played back on a DAC that can resolve both of them, then you are the one with a hearing issue - not 95% of the other people". Sorry, if you can hear that difference, go get your equipment fixed. Same if you can hear that between 44.1K and 192K.

Not a single human has been shown to hear, or perceive in any way, frequencies at 22.05K (or above). On the other hand, most gear, when given ultrasound input, does produce artifacts in the hearable range, so it's possible to distinguish those, but that's not hearing ultrasound but the gear having flaws. And it actually gives input without those high frequencies higher quality. For an accurate test, you need two separate speakers: one for the audible range, one for ultrasound. And such tests have yet to produce an individual that can tell them apart.

We really need an equivalent of the Randi prize for audiophiles.

On the other hand, the above applies only for OUTPUT. It is really non-trivial to implement a lot of processing algorithms without introducing audible errors, resampling between between different frequencies (such as 48K->44.1K) being one of them; thus, doing all editing at a highly exaggerated sample rates is a good idea. Yet actually sending that file to a speaker has no reason to be done at above 44.1K, Clementine's purpose is just that. Thus, it should accept high-rate INPUT but doesn't need to drive speakers that way.

Likewise, 16-bit is for all practical purposes enough. It's only almost beyond human ability, but you need an extreme setup to perceive it: a high-quality quiet room, speakers set to near the pain threshold, playing a sample that's silent except for the lowest bits.

[jkorten]

@kilobyte - you fail to understand the consequences the digital signal processing has in the audio band. It has nothing to do with frequencies above 22kHz. Although the high frequencies do improve with higher sample rates.

Your comment about ultrasound input is non-sensical. Nobody says that using higher sample rates puts ultrasonic frequencies in the signal chain. In fact most filters, as I said earlier, start filtering around 30kHz. Just like high end amplifiers. But you evidently are not reading, and in fact it appears you are in posession of "alternative facts".

Your comment about 16 bits is also completely ignorant. Resolution is one aspect, noise shaping another. But the difference between the two is completely audible, except to you I suppose.

So I see I'm dealing a band of ignoramuses who got control over a perfectly servicable player. Good luck and have fun in your world of shadows.

[kilobyte]

The massive amount of ignorance here comes from marketing drivel of vendors of "audiophile" gear. There's a huge industry whose paychecks comes from people not having the facts right.

No one contests the physics of signal processing. What you're missing is that, no matter how accurately you provide high sample rates or sample resolution, a human can't hear the result.

The images you presented show the physics, ie, what equipment sees. What we care about is ABX, ie, what humans hear. A difference that, despite objectively existing, is imperceptible by humans, doesn't matter as far as an audio player is concerned.

And, all this flamewar hides the real problem here, ie, no ability to select ALSA device. But I have an idea how to deal with that.

[jkorten]

I have no need to convert you, but if you are interested and you have access to a DAC that handles these sample rates - go here: http://www.2l.no/hires/index.html

The Benjamin Britten piece is a good example. On my SMSL M8 DAC which is cheap, I can hear the difference for each sample rate. (but I am using $500 Shure SRH1840 headphones) If you don't hear a difference, or its not important to you, you're lucky! You won't have to spend extra money in your life on good stereo equipment.

[andy-twosticks]

Arguments against audiophiles play against your strengths here. Does clementine want to drive away users or attract them? Genuine question. If you want to attract users and not drive them away, then the responses on this thread are not the way to do it.

I am no audiophile, and I suspect that, shorn of vitriol, most of the detrimental claims here are valid. But the rudeness here makes me want to stop using Clementine.

[Sal1950]

Yes, while HQPlayer, JRiver, Audivarna, Amarra, Roon, etc: players continue to attract non- Linux users to their platforms in large numbers what do we have? My only option has been a hacked version of PCLinuxOS with Clementine 1.2.3 pinned. When that build breaks updating of the rest of the OS it's over for Linux as my music server here. :(

[jcelerier]

@kilobyte

Not a single human has been shown to hear, or perceive in any way, frequencies at 22.05K (or above).

• This is factually wrong.

• See also this :

The present study shows that high-resolution audio that retains high-frequency components has an advantage over similar and indistinguishable digital sound sources in which such components are artificially cut off, suggesting that high-resolution audio with inaudible high-frequency components induces a relaxed attentional state without conscious awareness.

• This paper where the authors noted hearing of pure tones at 28khz

• And this note in Nature where the author says that through bone conduction, human can hear up to 100khz)

[Sal1950]

Thanks for the instructive post jcelerier. It is a very unfortunate position the developers have taken. This leaving us Linux users with little alternative for the playback of high data rate files in a bit perfect manner. Meanwhile there is a big rush in development of HD media players for the Windoz and Mac platforms. When the time comes that I can no long use my Linux desktop with my locked 1.2.3 build of Clementine do to conflicts, etc; I'll be forced to use Windoz for my music server. :(

[jkorten]

After learning what the maintainers of Clementine have decided to do to their player, I migrated to ap-linux and MPD using the Cantata client. I have to say the increment in sound quality is stunning. Huge large sound stage compared to running say Mint and Clementine. The trouble is the playlist functionality in Clementine is nice. So you can use it for parties (ap-linux which is Arch based). Those of your who are audiophiles should try it. It is a difficult install, and the MPD database takes a while to sync with Cantata (my collection is 2tb). But worth it on the listening end. The very problematic issue with computer audio is that it appears that no buffering/re-clocking is done on the data stream, probably a legacy issue for recording studios to keep things in semi real-time, but the jittering that occurs from the lack of re-clocking on input to the DAC (our out from the computer) seems to be a big problem for this method of audiophile listening. Ap-linux seems to be attempting to address this issue.

[Sal1950]

jkorten, I don't understand what you are saying here about the clock? I'm sure you're using a high quality outboard DAC and it is the DAC's responsibility to reclock the data stream and clean up any jitter. With any decent USB asynchronous DAC connection audible jitter should be a totally non-issue.

[jkorten]

As I say "it appears" which means I am guessing this is the reason. Otherwise why would an OS change make such a difference in sound? (My DAC during that switch was an MHDT Steeplechase.)

[jonaski]

I'm working on a fork of clementine, it's called strawberry. I've added this option back and it's working. I own a McIntosh dac myself. I've not yet pushed it out but check my profile for updates. Probably already aware of it but you can also configure alsa to bypass dmix if you put the following in /etc/asound.conf

pcm.!default { type hw card 0 device 0 }

ctl.!default { type hw
card 0 device 0 }

[Sal1950]

@jonaski, I "High Fidelity" fork would be super excellent. I'll be looking forward to it!

[tari01]

@jonaski, Great news!

By the way, I was also thinking about creating a fork, but never found the time. My idea was to call it "Lemon" and use a yellow Clementine icon.

[thomaspierson]

You should at least propose a pull request here before setting up a fork. Please don't split effort on free software project uselessly…

[kilobyte]

Hell yeah, a fork just for a single setting sounds really harmful.

Looks like we have two separate issues, both wanting this setting:

• people for whom PulseAudio doesn't work due to bugs
• power-users who want exotic configuration not supported by PulseAudio Clementine's authors don't want the old setting because it "can confuse users".

Thus, I guess the best way would be two-pronged: provide an easy control for newbies, and the full ALSA string for power-users. If the latter is to be hidden, it can be put into the config file without an associated widget in the UI. The latter ([GstEngine] device=hw:0) worked well even after removal from the UI, ending up broken only some time after 1.3.1. Lemme take a look at the for-newbies solution, someone else may repair the hidden config setting. Either would fix my use case.