How was MPD setup in the other scenario? Mint uses pulseaudio with its resampling mixer unless your player is setup to use alsa hw (plughw) device directly).
Now look at chains:
MPD - alsa hw running at any samplerate natively
or
MPD - resampling to 44100/ conversion to float32 - jack copying data from one memory location to another - conversion to int24 - alsa hw running at 44100
Or very likely your other chain:
MPD - pulseaudio resampling to 44100 - alsa hw running at 44100.
No pulse audio. A barebones stripped down install running text mode that launches jack and then mpd via upstart scripts.
This is how I used alsa with mpd when uncommented
#audio_output {
# type "alsa"
# name "Amanero"
# device "hw:2,0"
# device "cards.pcm.iec958"
# auto_resample "no"
# format "44100:16:2" # optional
# mixer_type "hardware"
# mixer_device "hw:2"
# mixer_control "Master"
#}
And this is how jack is setup
audio_output {
type "jack"
name "Music Player Daemon"
autostart "no"
format "44100:16:2"
}
I never saw int24 being used always
cat /proc/asound/Amanero/pcm0p/sub0/hw_params
access: MMAP_INTERLEAVED
format: S32_LE
subformat: STD
channels: 2
rate: 44100 (44100/1)
period_size: 256
buffer_size: 768
samplerate_converter is disabled. Absolutely no services running or listening on any port except mpd and sshd. All unnecessary init.d scripts and upstart scripts disabled at boot.
--G0bble
Last edited:
It is not resampling and as you can see there is no dmix involved either. I use only 16/44.1 flac files and I am ensuring it stays that way and is passed direct and untouched by using either or both hw and the iec device. I have also commented the format statement to test.
As for question 2 ALL listening is feeling. Conversely there is no listening without feeling
To be more precise, change in timbre, texture, and the communication of emotion.
--G0bble
Last edited:
OK, this works for your 44.1 flacs. Any track with a different rate will be hard-converted to 44.1. If you did not specify the samplerate in mpd.conf, the player would switch your soundcard appropriately, resulting in no samplerate conversion at all for most common samplerates.
As for question 2 ALL listening is feeling. Conversely there is no listening without feeling
I see, so you have only subjective experience with alsa vs. jack sound, you did not do any objective listening test revealing you can really tell any difference. That is an important additional information to your claim.
If you mean collecting a few audiophile ears in my room and doing A/B tests then no. The difference is so obvious its not worth the time and effort right now. BTW I hear a difference even by bumping the realtime priority of the mpd process up and down. I've settled for 92 (after extensive trials up and down from 91 to 99) rather than have both jack and mpd contend with 99 and this with jack and mpd assigned to one core each of the cpu.
G0bble
Sent from my GT-N7000 using Tapatalk
I played with JACK for a while and did not find any audible advantage. If anything, it just used way more CPU cycles than necessary.
I just use ALSA direct output to the hardware device and it is not "ordinary" at all. Perhaps "transparent" would be the term I would use. My DAC takes any samplerate and depth I throw at it, so there is no need for re-sampling. That is the best case scenario, IMO.
I just use ALSA direct output to the hardware device and it is not "ordinary" at all. Perhaps "transparent" would be the term I would use. My DAC takes any samplerate and depth I throw at it, so there is no need for re-sampling. That is the best case scenario, IMO.
Absolutely correct and this is not what jack was made for.
Jack is needed when you have more than one source playing
and need them to be in sync. It´s mainly a tool for musicians.
If you are listening to one source, low latency is pointless, it
does not matter if your song starts to play with some mS delay
and it does not need to be in sync with e.g. a synth connected
with midi.
Software is man made, therefore no surprises once you understand how it works.
Hmm you are in for many surprise then. While I am not a researcher myself, a decade back I have spent many years collecting post graduate level papers on tcp/ip performance modelling its behaviour. And guess what? Many of the improvements in the tcp/ip stack have come about only after statistical analysis has defied common logic, has surprised the developers about expected behaviour, and remodelled it in the light of new insights.
But this particular case I believe is not about software logic but how the process scheduling affects the electrical backplane of the system. At least thats my hunch.
G0bble
Sent from my GT-N7000 using Tapatalk
Now seriously, where do get this nonsense from ? Is this some kind of bizarre humor understandable only to you ?
Doing a blind listening test is pretty simple but you will never do it. It could ruin your world of feelings. I have been at this point many many times. Waste of time to discuss this with you.
Just please always accompany your claims with the "as I feel it" specifier, not to confuse other readers.
1. Software volume control can be provided by several layers - the actual application (e.g. VLC, MPD), pulseaudio, alsa softvol plugin
2. alsamixer is just an application operating the controls provided by alsa devices. Software volume in alsa is handled by the softvol plugin which performs volume control on any sample format, without any conversion: git.alsa-project.org Git - alsa-lib.git/blob - src/pcm/pcm_softvol.c
Ok thanks. So for 16 bit input samples, Softvol would calculate using only 16 bit word length?
My music collection is 16/44 ALAC and I have a 24/96 capable DAC that does not contain a hardware volume control.
If we assume the player is MPD based, then is there a configuration of MPD/ALSA that can take 16 bit samples, apply volume processing using 24 or 32 bits, then output 24 bit samples to the DAC?
My music collection is 16/44 ALAC and I have a 24/96 capable DAC that does not contain a hardware volume control.
If we assume the player is MPD based, then is there a configuration of MPD/ALSA that can take 16 bit samples, apply volume processing using 24 or 32 bits, then output 24 bit samples to the DAC?
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.