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." :(
#5344"

[kilobyte]

@tari01: and what are that card's subdevices (aplay -L|grep -A1 ^hw:)? aplay -L shows CARD=id instead of numbers these days but they're aliases.

[tari01]

@kilobyte

I'm on a netbook right now, so nothing fancy here, but the subdevices are shown with aplay -L|grep -A1 ^hw:

hw:CARD=Intel,DEV=0
HDA Intel, ALC269VB Analog

hw:CARD=Intel,DEV=3
HDA Intel, HDMI 0

The device is Intel, and it exposes two subdevices: ALC269VB Analog and HDMI 0

[Sal1950]

[sal@localhost ~]$ aplay -L
null
Discard all samples (playback) or generate zero samples (capture)
default:CARD=Intel
HDA Intel, ALC889A Analog
Default Audio Device
sysdefault:CARD=Intel
HDA Intel, ALC889A Analog
Default Audio Device
front:CARD=Intel,DEV=0
HDA Intel, ALC889A Analog
Front speakers
surround21:CARD=Intel,DEV=0
HDA Intel, ALC889A Analog
2.1 Surround output to Front and Subwoofer speakers
surround40:CARD=Intel,DEV=0
HDA Intel, ALC889A Analog
4.0 Surround output to Front and Rear speakers
surround41:CARD=Intel,DEV=0
HDA Intel, ALC889A Analog
4.1 Surround output to Front, Rear and Subwoofer speakers
surround50:CARD=Intel,DEV=0
HDA Intel, ALC889A Analog
5.0 Surround output to Front, Center and Rear speakers
surround51:CARD=Intel,DEV=0
HDA Intel, ALC889A Analog
5.1 Surround output to Front, Center, Rear and Subwoofer speakers
surround71:CARD=Intel,DEV=0
HDA Intel, ALC889A Analog
7.1 Surround output to Front, Center, Side, Rear and Woofer speakers
iec958:CARD=Intel,DEV=0
HDA Intel, ALC889A Digital
IEC958 (S/PDIF) Digital Audio Output
[sal@localhost ~]$

[Sal1950]

[sal@localhost ~]$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: Intel [HDA Intel], device 0: ALC889A Analog [ALC889A Analog]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: Intel [HDA Intel], device 1: ALC889A Digital [ALC889A Digital]
Subdevices: 1/1
Subdevice #0: subdevice #0
[sal@localhost ~]$

[Sal1950]

First 2 posts were my main tower/media server

These 2 are from my laptop just for more data,

[sal@localhost ~]$ aplay -L
null
Discard all samples (playback) or generate zero samples (capture)
default:CARD=Intel
HDA Intel, AD1981 Analog
Default Audio Device
sysdefault:CARD=Intel
HDA Intel, AD1981 Analog
Default Audio Device
front:CARD=Intel,DEV=0
HDA Intel, AD1981 Analog
Front speakers
surround21:CARD=Intel,DEV=0
HDA Intel, AD1981 Analog
2.1 Surround output to Front and Subwoofer speakers
surround40:CARD=Intel,DEV=0
HDA Intel, AD1981 Analog
4.0 Surround output to Front and Rear speakers
surround41:CARD=Intel,DEV=0
HDA Intel, AD1981 Analog
4.1 Surround output to Front, Rear and Subwoofer speakers
surround50:CARD=Intel,DEV=0
HDA Intel, AD1981 Analog
5.0 Surround output to Front, Center and Rear speakers
surround51:CARD=Intel,DEV=0
HDA Intel, AD1981 Analog
5.1 Surround output to Front, Center, Rear and Subwoofer speakers
surround71:CARD=Intel,DEV=0
HDA Intel, AD1981 Analog
7.1 Surround output to Front, Center, Side, Rear and Woofer speakers
iec958:CARD=Intel,DEV=0
HDA Intel, AD1981 Digital
IEC958 (S/PDIF) Digital Audio Output
[sal@localhost ~]$

[sal@localhost ~]$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: Intel [HDA Intel], device 0: AD1981 Analog [AD1981 Analog]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: Intel [HDA Intel], device 1: AD1981 Digital [AD1981 Digital]
Subdevices: 1/1
Subdevice #0: subdevice #0
[sal@localhost ~]$

[jkorten]

Use a comma not a period and you are good.

…

On Jul 10, 2017 6:38 PM, "Adam Borowski" ***@***.***> wrote: Could someone from the audiophile crowd quote some ALSA device strings you'd want to use? Are these just plain device:subdevice (hw:3.0) or something more? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#5344 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AI2x-wBVCxq90khRYZgzIJNUDK2neJyBks5sMqfjgaJpZM4IKzZz> .

[Sal1950]

Any chance of progress on this issue?
Linux still needing a great player that can output bit perfect streams to outboard DAC's etc.
Clementine was the best there was and still hoping something can be worker out.

[kilobyte]

@Sal1950: unless your use case involves multiple sinks (so Clementine's output doesn't go to the default), anything that would be settable can already be done via /etc/asound.conf.

As for me, on the desktop I bought a 1€ USB sound card which works with PulseAudio (so I have no less than 4 cards: built-in (unused), HDMI (neither monitor has speakers), PCI (connected to speakers) and the USB dongle (headphones)), while on laptops and SoCs where PulseAudio breaks I don't have the multiple sinks problem.

Thus, fixing the issue isn't a priority for me (doesn't scratch a personal itch anymore), but it sounds like #6079 should be good enough for you in most cases. You can setup the sinks in /etc/asound.conf then select one via the finder. I haven't actually looked at it, but I guess that unless you have more than one sink per card all should be ok.

[Sal1950]

etc/asound.conf does not exist in my PCLinuxOS build. There is a etc/asound.state which symlinks to var/lib/alsa/asound.state?
In any case that wasn't what we were hoping for, a menu choice like existed before 1.3. Not all Linux users are competent at editing files to get their media player to work as desired, myself barely so. How are we ever to attract Windows users if they can't accomplish their needs in the GUI?

asound.txt

[Sal1950]

@treebeard81, This relates to repairing Clementine how?

[dumbassrevealer]

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

Great comment, shows brains and an open mind.

Clementine is a great player which needs support for modern music formats.

My question is this: Why are you deliberately making life difficult for audiophiles from using Clementine? is it some kind of prejudice?

[Sal1950]

Yes it is unfortunate what has happened to Clementine, I'm not sure if it is currently being maintained by anyone? I still love it's UI and ability to sound good in a High Fidelity system. I don't have the knowledge to code myself or I would join the dev team. BUMMER

[tari01]

@dumbassrevealer, @Sal1950:

Nothing's lost: http://www.strawbs.org/

[Sal1950]

@tari01
I've requested PCLinuxOS dev's package this and add it to our repository.
TIA

[jkorten]

Thank you Sal1950 and tari01!!!

[dumbassrevealer]

@tari01, @jkorten, @Sal1950

Update: I recommend Strawberry in preference to Clementine. Binaries are available, but I compiled from source on two systems, no issues.

High resolution formats work by ALSA - and the sound is excellent.

Although I haven't tried it, there is support for Tidal and Deezer - I am waiting for Qobuz support.

My final advice, if anyone falls on this thread in future, is to move to Strawberry, and, and I recommend repos managers to include it in preference to Clementine, or offer both.

[Sal1950]

There is now a Strawberry package in the PCLinuxOS repository. I've installed it to a couple of my boxes and it's running perfectly in all. Getting high res streams to my Emotiva DAC up to 192 kbps. Kudos to the coder for the ability to recognized the device automagically. The user no longer has to know the needed commands, etc.

[tari01]

Just a quick note:

Disclaimer:
I am not affiliated with @jonaski - the developer behind Strawberry, nor do I know the person in any way.

To all new users of Strawberry:
Strawberry does not only give us bit-perfect playback, but also fixes some of Clementine's major other issues. Please, encourage the developer by letting him know you appreciate the effort - I think simply mentioning @jonaski is quite enough. Trust me as a long-time amateur hobbyist developer, it really means a lot when you receive some positive feedback from the community once in a while.

To the Clementine team, as well as the rest of you:
The people behind Clementine have done something fantastic: they took Amarok and turned it into a light, beautiful and friendly piece of software for all of us to enjoy, my absolute favourite music player for many years. Strawberry has done the same, building upon the Clementine base - both proving why open-source development is so much superior to all other means of free software distribution.

And finally:
Both Amarok and Clementine are heavily featured in web searches and also present in the repositories for nearly all Linux distributions. Strawberry is fairly unknown. If you have a way of spreading the word, help Strawberry take its place next to its ancestors: let people hear about it, and help it get into official repositories.

Thank you Amarok, Clementine and @jonaski

[kilobyte]

It seems wasteful to me to have two nearly-identical music players. There's a massive difference between Amarok and Clementine, but patches between Clementine and Strawberry look mergeable.

[dumbassrevealer]

Good point @tari01 - @jonaski thanks for your excellent work! :-) :-)

@kilobyte, as far as I can gather, this is the reason why: "I don't think we care about "audiophile" things."

@jonaski does, and created Strawberry to cater for our strange desires.

[Sal1950]

@dumbassrevealer, yes for 2 years we begged the developers to reintroduce the code that allowed configuration of Clementine to direct the datastream directly to alsa. Without it the awesome application became useless to Linux audiophiles that had spent large amounts of money on high resolution recordings and the custom DAC's they used to replay them. We were told by @hatstand that our "audiophile things" didn't matter and that a very easily reintroduced bit of functionality would not be forthcoming. :(
This was a sad situation from an attitude perspective that left Linux audiophiles without a quality alternative. Since that time I've have to build a total special configured version of PCLinuxOS that still used a older 1.2.3 version of Clementine and it's supporting gstreamer lib's etc for our critical music listeners. A lot of work just to have a version of Clementine that supported the interests of people who cared about high quality music reproduction.
Thank You @jonaski for stepping up to help us!

[rijnhard]

I can't take away from all the great work that has been done on Clementine, but I also can't tell you how sad this is (as an audiophile) and on an emotional level to have been so (I'm going to say) naively dismissed. I get the reasoning, but I do believe it's flawed, and as such I have moved to strawberry

[tomachinz]

Ah thanks a bundle, I will checkout Strawberry!

[Stele77]

Just switched fully to Linux, but have used Clementine for many years on Windows before i then used Musicbee for the last years. Thought Clementine was the way to go on Linux too. I am not a super duper Hifi guy, just someone with lossless music and normal quality gear wanting to have control over the playback chain.
And I just want to add I am stunned by this arrogance (Dont know a nicer word for it, sorry).
When i read about this elsewhere, i could not believe it. But yeah, just stunning.. Without any reasoning, discussion or explantion. Just f..k you.
Great spirit never mind social skills.
Goodbye.

[bobemoe]

Wow yeah Strawberry FTW! Default config just worked with ALSA! :)

I'm building a minimal embedded system and wanted a decent player without all the bloat of pulse audio and its dependencies.

[Sal1950]

Wow yeah Strawberry FTW! Default config just worked with ALSA! :)

I'm building a minimal embedded system and wanted a decent player without all the bloat of pulse audio and its dependencies.

Yes sad that hatstand chose to take that path and shoot Clementine in the head like that.
My favorite Linux distro, PCLinuxOS, dropped Clementine and switched to Strawberry for their default media player some time back now. If you love music, Strawberry's the one to have. ;)

[Bluscream]

@hatstand are you just an UBER troll or are you actually such a big asshole?