Thanks, I don't currently use pulse in most of my music server installs. But I'm curious on how it will output the sound from the Spotify app and Kody. My pulse packages are at 13.0. We'll see how this works out.
-
Welcome to ASR. There are many reviews of audio hardware and expert members to help answer your questions. Click here to have your audio equipment measured for free!
BEGINNER QUESTION : Getting "BitPerfect" output in Linux ?
- Thread starter PenguinMusic
- Start date
The `avoid_resampling` option was introduced with version 11 of Pulse Audio. Version 13 definitely has this option. Also, do note that prior to this you could have set the option `alternate-sample-rate` to whatever your high res music is in - and setting that option is still doable of course.
And again, if you have music in DSD format, then that will not be sent natively to your DAC.
@PenguinMusic, run `pacmd list-sink-inputs` in a terminal while trying to play 96kHz audio, and take a peek at what Pulse reports the sample spec to be.
Personally, I've been using the aptly named dsp program with rather great success for the past few weeks now. I think it is easier to deal with than Pulse Effects and I highly recommend it. `dsp` should work with native ALSA output as well but I haven't tried that myself.
And again, if you have music in DSD format, then that will not be sent natively to your DAC.
@PenguinMusic, run `pacmd list-sink-inputs` in a terminal while trying to play 96kHz audio, and take a peek at what Pulse reports the sample spec to be.
Personally, I've been using the aptly named dsp program with rather great success for the past few weeks now. I think it is easier to deal with than Pulse Effects and I highly recommend it. `dsp` should work with native ALSA output as well but I haven't tried that myself.
My guess is that your Marantz pre/pro isn't recognized by the kernel's sound USB quirks driver as supporting DSD natively. One thing you can try is setting "dop" to "yes" in your mpd audio_output config stanza for your pre/pro, assuming it supports DSD-over-PCM.
MRC01
Major Contributor
The alternate-sample-rate setting never worked on my systems. When I set it to 96k, Pulseaudio still resamples everything - including 96k files - to 44.1k. It seems to simply ignore this setting.
The new avoid_resampling setting does work on my systems.
Interesting. It should have worked, as long as you actually only have one source playing. Running `pacmd list-sink-inputs` as I mentioned before, can help finding out what is actually being sent to PA. Likewise, PA can also be too helpful in autodetecting your setup sometimes and running `pacmd list-sinks` can also help iron out some kinks in how it operates.
FeathersMcGraw
Member
Hi,
I wanted to thank the contributors to this thread. I've learned a few new things
as a result of your generosity. One is the relatively recent addition of the
avoid_resampling configuration option of PulseAudio. I've tried it and seems
to work well.
I have seen some posts on other forums suggesting the complete removal of
PulseAudio in order to achieve bit perfect playback. That's not what's going
on here, fortunately.
PulseAudio does its job well, which is to mux a multitude of audio sources
together. When performing critical listening, it is almost invariably precisely
one audio source to the exclusion of all others.
On the distributions I've tried, many of the software packages that collectively
implement a given desktop environment often list PulseAudio as a dependent
package. Thus removing PulseAudio pretty much means gutting some of the
desktop environments. Fortunately, there's no reason to do this.
What I've been doing for quite a few years is using audio players that provide
for the ability to send the audio output directly to the DAC via ALSA, bypassing
PulseAudio. There are several discussed in this topic thread. Some of which
are new to me. My journey is much like others here. Amarok, then Clementine
then DeadBeef, with a few others auditioned at the transitional junctures.
Independent of player choice. What I do is let all of the usual audio sources
flow into the PulseAudio audio bus, as is largely done by default. I leave
PulseAudio with its output directed at an audio sink that I do not use for critical
listening. I then either lower the volume or mute PulseAudio and its current
audio sink. Basically using PulseAudio in a manner analogous to /dev/null,
or if you prefer, a default graveyard for all audio sources that I don't want to hear.
The audio player with which I am performing critical listening goes directly to
the intended DAC via ALSA. It is important to note that PulseAudio does
present its own ALSA interface. An aplay -L command on the Fedora system
on which I'm typing this message shows "pulse" and "default" as selectable
ALSA devices that are in fact audio inputs to PulseAudio. So, don't select those,
as you'll end up back where you started.
So, I find the simple solution is to use a player that is ALSA friendly. Use it for
your critical listening. Let PulseAudio continue to be the default audio muxer
for system sounds and other applications. Then mute PulseAudio while its
output is directed at some audio sink other than the one used for critical
listening. The only complexity is curating a list of favored audio players that
make it convenient to select the desired audio sink.
Appologies for stating the obvious and repeating what others have already said.
I just wanted to summarize because some users new to GNU/Linux might be
given the false impression that the topic of achieving quality audio playback on
GNU/Linux is difficult.
I wanted to thank the contributors to this thread. I've learned a few new things
as a result of your generosity. One is the relatively recent addition of the
avoid_resampling configuration option of PulseAudio. I've tried it and seems
to work well.
I have seen some posts on other forums suggesting the complete removal of
PulseAudio in order to achieve bit perfect playback. That's not what's going
on here, fortunately.
PulseAudio does its job well, which is to mux a multitude of audio sources
together. When performing critical listening, it is almost invariably precisely
one audio source to the exclusion of all others.
On the distributions I've tried, many of the software packages that collectively
implement a given desktop environment often list PulseAudio as a dependent
package. Thus removing PulseAudio pretty much means gutting some of the
desktop environments. Fortunately, there's no reason to do this.
What I've been doing for quite a few years is using audio players that provide
for the ability to send the audio output directly to the DAC via ALSA, bypassing
PulseAudio. There are several discussed in this topic thread. Some of which
are new to me. My journey is much like others here. Amarok, then Clementine
then DeadBeef, with a few others auditioned at the transitional junctures.
Independent of player choice. What I do is let all of the usual audio sources
flow into the PulseAudio audio bus, as is largely done by default. I leave
PulseAudio with its output directed at an audio sink that I do not use for critical
listening. I then either lower the volume or mute PulseAudio and its current
audio sink. Basically using PulseAudio in a manner analogous to /dev/null,
or if you prefer, a default graveyard for all audio sources that I don't want to hear.
The audio player with which I am performing critical listening goes directly to
the intended DAC via ALSA. It is important to note that PulseAudio does
present its own ALSA interface. An aplay -L command on the Fedora system
on which I'm typing this message shows "pulse" and "default" as selectable
ALSA devices that are in fact audio inputs to PulseAudio. So, don't select those,
as you'll end up back where you started.
So, I find the simple solution is to use a player that is ALSA friendly. Use it for
your critical listening. Let PulseAudio continue to be the default audio muxer
for system sounds and other applications. Then mute PulseAudio while its
output is directed at some audio sink other than the one used for critical
listening. The only complexity is curating a list of favored audio players that
make it convenient to select the desired audio sink.
Appologies for stating the obvious and repeating what others have already said.
I just wanted to summarize because some users new to GNU/Linux might be
given the false impression that the topic of achieving quality audio playback on
GNU/Linux is difficult.
- Joined
- May 25, 2019
- Messages
- 158
- Likes
- 218
Hi! Please check my github repository (see my signature). I have my current configuration that works very well. I relied on multiple online sources for this, as well as communication with Tanu Kaskinen, a pulseaudio developer.
MRC01
Major Contributor
I never got ALSA to work at the same time as pulseaudio. When using PA, anything that tries to use ALSA causes conflicts - one locks the other out of the sound hardware. When I use the Linux PC for listening to music, I disable PA and use ALSA. This has the advantage of locking all other apps out of the sound hardware so the music is never interrupted by system sounds. When I'm done listening, I re-enable PA.
This is my experience also but when I'm doing serious listening I'm not doing anything else on the computer. Once I start Strawberry or Cantata, that are config'd to feed directly to Alsa, nothing from PA ever tries to break thru..
I do have some small final issues with trying to get native pcm quad files to play back correctly. Strawberry either gets channel positions wrong or the rear channels are silent even though the AVR lights show it's receiving a quad file. Also Strawberry won't accept dsf or dff file in my distros build with a error it doesn't recognize the file type. I believe this is a failing of Strawberry everywhere.
Cantata plays all types of dsd files without issue but does choke on some quad files.
Getting all forms of stereo and multich files performing correctly in Linux can be a bit of an exercise but Widnoz is no cakewalk either.
FeathersMcGraw
Member
Are you perhaps trying to have both PulseAudio use device A as its sink while also using
an audio application sending its audio output directly to device A via ALSA? If so, that
would definitely explain the conflict. When I recreate that scenario, VLC for example, gives
the following error.
With PulseAudio currently selecting the D10 as its output and playing audio.
vlc --aout=alsa --alsa-audio-device="front:CARD=D10,DEV=0" some_song.flac
produces
alsa audio output error: cannot open ALSA device "front:CARD=D10,DEV=0": Device or resource busy
Directing the PulseAudio output to an audio sink other than the D10 resolves the
conflict and VLC (used in this example) is able again to play to the D10.
It's quite possible that I'm failing to understand your circumstance, my appologies.
OP
PenguinMusic
Addicted to Fun and Learning
- Joined
- Dec 20, 2019
- Messages
- 692
- Likes
- 429
- Thread Starter
- #151
Hi guys,
Anyone in here been able to output something else than 16/44 from Chromium (or any other browser) while streaming music from "hi-res" web sites ?
I have tried to listen to "24/96" files streamed over Qobuz. They only show up as 44khz...
If so, how is this done ?
Thanks a lot.
Anyone in here been able to output something else than 16/44 from Chromium (or any other browser) while streaming music from "hi-res" web sites ?
I have tried to listen to "24/96" files streamed over Qobuz. They only show up as 44khz...
If so, how is this done ?
Thanks a lot.
MRC01
Major Contributor
Yes, I think so. Problem is, my card has only 1 analog output and it seems that ALSA & PA can't share it. Is it possible to create a second driver sink for the same physical hardware?
OP
PenguinMusic
Addicted to Fun and Learning
- Joined
- Dec 20, 2019
- Messages
- 692
- Likes
- 429
- Thread Starter
- #153
Hi,
Indeed it is not possible to share.
If the sink is already in use by Pulse (or by any other app also using ALSA), your player will say "Cannot use the selected out put. Already in use". Or something similar.
If the sink is already in use by ALSA, if you open an app needing PulseAudio, it will simply not play... at all giving you the impression something's wrong with your system.
Me, I am forutnate enough to use a DAC that has USB and TosLink input.
So I use TosLink with ALSA and USB with Pulse...
Requires to switch the input on the DAC though...
somebodyelse
Master Contributor
- Joined
- Dec 5, 2018
- Messages
- 5,350
- Likes
- 4,937
Just to be clear on the layers here, ALSA provides the logical interface to the sound card. Apps can connect to the ALSA interface directly, or to PA which in turn connects to the ALSA interface, or to Jack which sits in a similar position to PA.
You can use ALSA's dmix interface if you want to have multiple things connecting to the ALSA device, but that just resamples to a fixed rate, mixing the sources as the name implies, so I don't think it's what you want. In my experience it also causes sync problems with PA after apps using it have been playing for a while. I'm using it as I have squeezelite as a system level daemon, but firefox demands PA and doesn't work with apulse, and the speakers on this system aren't good enough to worry so much about quality. I am interested in a better option, but haven't put the time into finding it yet.
You can create other devices in asoundrc, but I _think_ that has the same limitation on simultaneous connections as the underlying device. You can also create a pair of virtual interfaces with alsaloop. This might be an option if using Jack as a virtual patchbay to switch between PA and the app(s) but it's not exactly user-friendly.
FeathersMcGraw
Member
My bad. I made the assumption that most systems have multiple audio sinks.
Typically a collection of a built in sound card, one or more HDMI High Definition
Audio (HDA) ports, and a USB DAC set aside for critical listening.
If only one audio sink available, I think what MRC01 is doing makes sense.
Though this relatively new avoid-resampling feature is thus far working
rather nicely and has me rethinking my approach. Thank you all for making
me aware.
I also have a new found appreciation for the diversity of use cases. I hadn't
realized that some of the streaming audio services are often used through
browsers. This not so young padawan has much to learn. Thank you for
sharing your wisdom.
Typically a collection of a built in sound card, one or more HDMI High Definition
Audio (HDA) ports, and a USB DAC set aside for critical listening.
If only one audio sink available, I think what MRC01 is doing makes sense.
Though this relatively new avoid-resampling feature is thus far working
rather nicely and has me rethinking my approach. Thank you all for making
me aware.
I also have a new found appreciation for the diversity of use cases. I hadn't
realized that some of the streaming audio services are often used through
browsers. This not so young padawan has much to learn. Thank you for
sharing your wisdom.
dudodelmundo
Member
- Joined
- Dec 2, 2019
- Messages
- 26
- Likes
- 1
Hi there,
is there a way to pass audio from the qobuz webplayer in hires to a dac?
192 khz chromium>alsa>dac ?
As far as i know pulseaudio in the middle makes hires ******. I would like to have nice webui to look at and have the hires as subscribted. Any ideas? mpd is too nerdy and roon to expensive but nice.
Thanks.
is there a way to pass audio from the qobuz webplayer in hires to a dac?
192 khz chromium>alsa>dac ?
As far as i know pulseaudio in the middle makes hires ******. I would like to have nice webui to look at and have the hires as subscribted. Any ideas? mpd is too nerdy and roon to expensive but nice.
Thanks.
No, not AFAIK. It will take Qobuz to write a dedicated app for Linux as they did for Windoz, one with the tools to direct the stream to Alsa as some of the media players offer.
I use BubbleUPNP on Android with Qobuz. The app instructs my DLNA client on Linux to play the Qobuz stream.
In this case the app is the one with access to the Qobuz API and my credentials. The player is just streaming what it's told and had no knowledge of either.
In this case the app is the one with access to the Qobuz API and my credentials. The player is just streaming what it's told and had no knowledge of either.
dudodelmundo
Member
- Joined
- Dec 2, 2019
- Messages
- 26
- Likes
- 1
Qobuz app itsself is nice too. Allows chromecast ultra to show a nice gui. But then i have to extract audio with a hdmi splitter to go into my dac. What i like about qobuz webplayer is that it looks nice. mpd does everything too but isnt very attractive.
maybe i sholud try this out:
apulseAUR lets you use ALSA for applications that support only PulseAudio for sound. Usage is simply $ apulse yourapplication.
Does your DAC report receiving the data stream speed of the song your listening to? IE do you see it change from 44 to 96 or 192 if that's what the source is providing?