[SOLVED]Audio routed through alsa, but why is there still resampling?

archuser_9999 · 2024-10-10 10:23:59

Firstly, my audio replay works. I'm very content to simply let alsa do basic stuff, I have no need for additional subsystems like Pulse etc.

I'm asking for advice/help for the following reason:

Been using Cantata music player, running mpd as user, for years now with no issues.

But whatever recent change in some part of some update has caused it, I ended up having just one and only one audio file (mp3) that consistently produces "garbage" at certain points in the song. To help focus replies, I can state that the file is good, and the "garbage" does not show up under any other replay i.e. through Audacity, kid3 etc.

I've spent a day or more re-reading wikis, recreating config files etc. My current .asoundrc uses their own suggested basic setup:

pcm.!default {
        type hw
        card 0
}

ctl.!default {
	type hw           
	card 0
}

but when I look at my logs while music is playing via mpd I see the following:

Oct 10 11:57:43 Snazz mpd[568]: libsamplerate: libsamplerate converter 'Fastest Sinc Interpolator'
Oct 10 11:57:43 Snazz mpd[568]: vorbis: Xiph.Org libVorbis 1.3.7
Oct 10 11:57:43 Snazz mpd[568]: opus: libopus 1.5.2
Oct 10 11:57:43 Snazz mpd[568]: sndfile: libsndfile-1.2.2
Oct 10 11:57:43 Snazz mpd[568]: hybrid_dsd: The Hybrid DSD decoder is disabled because it was not explicitly enabled
Oct 10 11:57:43 Snazz mpd[568]: decoder: Decoder plugin 'wildmidi' is unavailable: configuration file does not exist: /etc/timidity/timidity.cfg
Oct 10 11:57:43 Snazz mpd[568]: simple_db: reading DB
Oct 10 11:57:43 Snazz mpd[568]: input: Input plugin 'qobuz' is not configured: No Qobuz app_id configured
Oct 10 11:57:43 Snazz mpd[568]: curl: version 8.10.1
Oct 10 11:57:43 Snazz mpd[568]: curl: with OpenSSL/3.3.2
Oct 10 11:57:43 Snazz mpd[568]: state_file: Loading state file /home/xxxx/.config/mpd/mpd_state
Oct 10 11:57:43 Snazz mpd[568]: inotify: initializing inotify
Oct 10 11:58:06 Snazz mpd[568]: inotify: watching music directory
...

OOct 10 11:58:22 Snazz mpd[568]: client: [4] process command "idle"
Oct 10 11:58:22 Snazz mpd[568]: client: [4] command returned 1
Oct 10 11:58:22 Snazz mpd[568]: mad: detected LAME version 3.100 ("LAME3.100")
Oct 10 11:58:22 Snazz mpd[568]: mad: LAME peak found: 0
Oct 10 11:58:22 Snazz mpd[568]: mad: encoder delay is 576, encoder padding is 924
Oct 10 11:58:22 Snazz mpd[568]: decoder: audio_format=44100:24:2, seekable=true
Oct 10 11:58:22 Snazz mpd[568]: alsa_output: opened hw:0,0 type=HW
Oct 10 11:58:22 Snazz mpd[568]: alsa_output: buffer: size=32..524288 time=725..11888617
Oct 10 11:58:22 Snazz mpd[568]: alsa_output: period: size=16..262144 time=362..5944309
Oct 10 11:58:22 Snazz mpd[568]: alsa_output: default period_time = buffer_time/4 = 500000/4 = 125000
Oct 10 11:58:22 Snazz mpd[568]: alsa_output: format=S32_LE (Signed 32 bit Little Endian)
Oct 10 11:58:22 Snazz mpd[568]: alsa_output: buffer_size=22050 period_size=4410
Oct 10 11:58:22 Snazz mpd[568]: output: opened "PCH" (alsa) audio_format=44100:32:2
Oct 10 11:58:22 Snazz mpd[568]: output: converting in=44100:24:2 -> f=44100:24:2 -> out=44100:32:2
Oct 10 11:58:22 Snazz mpd[568]: client: [3] process command "status"
Oct 10 11:58:22 Snazz mpd[568]: client: [3] command returned 0
Oct 10 11:58:22 Snazz mpd[568]: client: [3] process command "replay_gain_status"
Oct 10 11:58:22 Snazz mpd[568]: client: [3] command returned 0
Oct 10 11:58:22 Snazz mpd[568]: client: [4] process command "idle"
Oct 10 11:58:22 Snazz mpd[568]: client: [4] command returned 1
Oct 10 11:58:22 Snazz mpd[568]: client: [3] process command "status"
Oct 10 11:58:22 Snazz mpd[568]: client: [3] command returned 0
Oct 10 11:58:22 Snazz mpd[568]: client: [3] process command "replay_gain_status"
Oct 10 11:58:22 Snazz mpd[568]: client: [3] command returned 0
Oct 10 11:58:22 Snazz mpd[568]: client: [4] process command "idle"
Oct 10 11:58:22 Snazz mpd[568]: client: [4] command returned 1
Oct 10 11:58:27 Snazz mpd[568]: client: [3] process command "status"
Oct 10 11:58:27 Snazz mpd[568]: client: [3] command returned 0
Oct 10 11:58:32 Snazz mpd[568]: client: [3] process command "status"
Oct 10 11:58:32 Snazz mpd[568]: client: [3] command returned 0
Oct 10 11:58:37 Snazz mpd[568]: client: [3] process command "status"
Oct 10 11:58:37 Snazz mpd[568]: client: [3] command returned 0
Oct 10 11:58:37 Snazz mpd[568]: client: [3] process command "pause "1""
Oct 10 11:58:37 Snazz mpd[568]: client: [3] command returned 0
Oct 10 11:58:37 Snazz mpd[568]: client: [3] process command "status"
Oct 10 11:58:37 Snazz mpd[568]: client: [3] command returned 0
Oct 10 11:58:37 Snazz mpd[568]: client: [3] process command "replay_gain_status"
Oct 10 11:58:37 Snazz mpd[568]: client: [3] command returned 0
Oct 10 11:58:37 Snazz mpd[568]: client: [4] process command "idle"
Oct 10 11:58:37 Snazz mpd[568]: client: [4] command returned 1
Oct 10 11:58:37 Snazz mpd[568]: output: closed "PCH" (alsa)
Oct 10 11:58:42 Snazz mpd[568]: client: [3] process command "status"
Oct 10 11:58:42 Snazz mpd[568]: client: [3] command returned 0
Oct 10 11:58:48 Snazz mpd[568]: client: [3] process command "status"
Oct 10 11:58:48 Snazz mpd[568]: client: [3] command returned 0

What I find undesirable is that instead of doing what I believed I had configured, and which is to please just pass the music stream direct to my sound chip via Alsa, instead there seems to be all this invoking of Speex conversion, and my audio being output at 32 bit.

I'm less concerned with "fixing" my mpd replay (because Cantata has long been archived, and it's time to change, and probably drop mpd entirely) but am concerned that once I switch to a new audio player (such as Quod Libet), I may run into similar issues.

Am I simply misunderstanding some aspect of alsa via "hw control" (I gather that direct to hardware disables dmix) and that what I'm seeing above is something to do with the codecs that my sound chip uses (Realtek ALC892) and is thus "unavoidable"?

What I am trying to achieve is pure "pass through" of audio - just take the mp3 and pass it to the hardware, and DO NOT resample or alter it in any way.

Last edited by archuser_9999 (2024-10-20 15:11:24)

V1del · 2024-10-10 10:50:18

The audio device is opened at a S32_LE sample rate. This is how mpd opens it, check it's settings. https://mpd.readthedocs.io/en/stable/us … t-settings and https://mpd.readthedocs.io/en/stable/pl … lsa-plugin for alsa plugin specific configuration options

FWIW since the relevant conversion is only going from lower (24) to higher (32) that shouldn't lead to any noticable impact in a general sense (.. it can just 0-pad the excess bits).

What rates are supported by your sound card in the first place? compile e.g. https://download.atmark-techno.com/misc … w_params.c and run it while nothing's playing

Last edited by V1del (2024-10-10 10:52:46)

archuser_9999 · 2024-10-10 11:46:03

Many thanks for the help. In fact I had a response from the mpd devs, who have decided this is basically nothing to do with them, so on that basis I'm ditching mpd (I have no need at all for serving music anyway) and going with a player that has its own output.

Manufacturer specs for my sound chip state that:

All DACs supports 44.1k/48k/96k/192kHz sample rate

and I know from previous exploration that it supports 16|24|32 bit depth.

I do appreciate that zero padding isn't going to necessarily colour the output, and I have no issues with latency or loading. So in one sense it might be fair to say "why worry" but in another... why on earth does a player have to mess with my audio at all? Surely it can simply replay the file as is without any need to resample - granted of course that we are converting from PCM to analogue to the speakers.

V1del · 2024-10-10 12:23:27

Well the thing is, that you need to do some decisions on how to open the device before you play back anything, you can't change that on the fly without closing the output. That the player decides to do resampling by default makes sense as it's much easier to control and guarantee you get any audio (... assuming your device doesn't support a given sample rate, would you rather to not hear anything or just see a bit of a bump in CPU?). If a proper resampler is used and you don't have a low power device then even if "more cpu is burned" you're generally not going to hear any difference from resampling happening.

Last edited by V1del (2024-10-10 12:25:10)

archuser_9999 · 2024-10-10 12:38:21

I can totally accept this yes. And ordinarily none of this would bother me. I'm not obsessed - if it works, don't try to fix it.

But as per my OP, I have encountered this bizarre situation wherein just ONE single mp3 track continues to produce audio garbage on replay. And please note, I am indeed obsessive about my music library. So of the ~800Gb of files it contains, I have assiduously tagged, sorted, mp3Diag the heck out of it such that every single file is "correct".

So, I don't have any low bit files. Everything is correct in terms of being 256 or above (VBR max being preferred). And yet, despite days and days of head scratching, double checking etc. I STILL have this mp3 that deals garbage ONLY when played via mpd. If I play it with anything else it's fine. The file isn't corrupted.

This is why I ended up wanting to dig into what was happening, and why would (despite we can agree that "it won't do any harm") my files need to be passed to and fro through layers of processing, when ALL I need my player to do is please read back to me the file I have stored (so to speak). One might say that I consider the sound circuits in my PC to be the equivalent of a 24bit CD player, so far has technology advanced that one can cram onto a sound card what used to require a large standalone piece of hardware.

I get that replaying audio on a computer is actually a ferociously complicated thing, but that said these things all offer user configuration.

I'm currently working out an .asoundrc that simply sets the default device to 44.1, 16 bit stereo, and as such can then tweak that to ensure that this is only applied when replaying my music library, and allows other sound e.g. Youtube audio, Spotify to do whatever the heck makes it happy.

I get that 48K/96K, 32bit audio is easy for a sound chip to do now, so it's a handy default, but I don't want my music mangled with if possible. Otherwise, why even bother having book standards for such things if they all just end up getting reinterpreted on the fly?

V1del · 2024-10-10 12:44:32

Well have you checked the configuration options I linked? You can explicitly configure mpd to not do resampling and pass the audio as is.

archuser_9999 · 2024-10-10 12:50:36

I did see that link, thank you. Unfortunately my brain froze at "compile this".

However I will look again - I wasn't attempting to be rude in any way, just that what's obvious and simple to one person may not be to another.

For the purposes of gaining a fuller understanding, I shall go and find out how to compile said script, and I will indeed look closely at the options. All of which said... I think I'm done with mpd now anyway. It's clever yes, but with hindsight quite WHY I have read, puzzled, sweated over so many configs and long dry documentation when all I've ever wanted was to simply have my music replayed untouched (within above context)?

The older I get, the more I admire simplicity.

V1del · 2024-10-10 13:10:37

No the script is simply to identify which sample rates/formats are in theory supported on your hardware. This has absolutely no relevance on the behaviour of MPD or anything else for that matter. If you want to configure how MPD handles your audio device and distinct audio files you can configure that via standard configuration file of MPD, where it can be explicitly configured to not do resampling on it's own.

It almost always makes sense as a default setting to do resampling, as not playing back due to format differences are going to be more noticable to the vast majority of people, rather than the audio getting "altered" in some form

I'd also say chances are you are barking up the wrong tree. How do you know the garbage issue is due to resampling? How certain are you the other players you tested haven't done any resampling of their own?

Last edited by V1del (2024-10-10 13:12:14)

archuser_9999 · 2024-10-10 13:25:19

I don't know that other players haven't done any resampling. What I do know is that the issue only occurs using mpd via Cantata. And since I cannot make the issue go away I began investigating alternatives. Looking at journal output, it seems mpd cannot but help itself to load up Speex converter, and a bunch of other useless entities. Why is it telling me that it cannot find the .config file for 'wildmidi' (pulled in as a dependency)? Is there an option to disable this in mpd.conf? I've read the entire docs, and all the details on each section e.g. audio outputs, plugins etc. No mention of disabling resampling anywhere. Unless you're saying that I should simply "brute force" mpd to only output 44.1|16_LE|stereo is the way to go. And does this then disable mpd's internal machinations that seem to want to use libsndfile library?

I replayed the problem file through MPV. Didn't flinch. Didn't make me want to look under the hood either. So as I say, this is part curiosity now and wanting to understand, and part the fact that I've decided mpd is complete overkill for my uses anyway, so I'll dump it in favour of something simpler.

It's not clear to me why you think that "why not resample anyway" is better than "these are my (entirely correct) files, please just replay them", but I am very happy to understand the thinking behind your conclusion. Feel free to post any links or resources.

V1del · 2024-10-10 14:40:25

Generally you shouldn't worry too much about the libs mpd will use to get to the end goal, I doubt you can infer anything from the fact libsndfile is being loaded -- it will simply load the libs with the support it got built with/for.

The second link to the mpd docs for the alsa device settings mentions the properties auto_format = yes, auto_resample = yes and auto_channels = yes all of which are yes by default and can be switched to no instead.

I'm not saying it's better for your usecase. -- if you happen to have one that is that curated -- but for the vast majority of people they are not going to notice nor care about whether a file gets resampled and the alternative would be to not play the file at all which is worse -- seeing as resampling done properly will have no audible impact on the end result.

As for configuring which plugins mpd loads that is also configurable... but also irrelevant for the task at hand. But if you generally want to switch away from mpd, then the question of whether it will properly do bit-perfect playback without resampling needs to be looked at in the context of said player you're opting to use instead.

Last edited by V1del (2024-10-10 14:43:39)

archuser_9999 · 2024-10-10 14:55:16

again helpful, thank you.

My config is this

# Files and directories #######################################################
music_directory		"~/Music"
playlist_directory  "~/.config/mpd/playlists"
state_file			"~/.config/mpd/mpd_state"
# log_file			"~/.config/mpd/mpd_log"
log_level			"verbose"
restore_paused "yes"
save_absolute_paths_in_playlists	"yes"
metadata_to_use	"artist,album,albumartist,title,track,genre,date,composer,performer,disc"
metadata_to_use "+comment"
auto_update	"yes"

# Database ####################################################################
database {
	plugin "simple"
	path "~/.config/mpd/mpd_db"
}

# Audio Input #################################################################
input_cache {
	size "1 GB"
}

# Audio Output ################################################################
audio_output {
	type			"alsa"
	name			"PCH"
	device			"hw:0,0"
	auto_resample	"no"
	auto_format		"no"
	replay_gain_handler		"mixer"
	
}

filesystem_charset		"UTF-8"

but no, I did not find the part yet which would allow me to stipulate that mpd loads no external plugins at all. Will look at that again.

And I am not disagreeing with you or anyone who says that resampling 'shouldn't' matter, just as I'm not saying that I would hear any difference. But it is very important to keep in mind part of my original post, which I'll repeat again here: there is ONE file, among the 70K mp3 files I have, and which is only recently added, and which - when exclusively played via mpd - has audio noise in it.

Thus, being rather circular here, I am unable to make this noise go away! The file itself is fine, this noise does not appear anywhere else. The mpd devs suggested this has nothing to do with them, so I can't get any help there.

What am I supposed to do? I posted here hoping that some wise soul might direct me towards some deeper level of inspection/analysis during replay that might help me get to the bottom of why just this one single file creates this anomaly. Instead of which I find myself debating (fascinating as it is) the merits or demerits of using mpd. Clearly this is some relationship between what I currently have configured, and why there is some strange 'saturation' or whatever of the audio output during this one song. And we're talking country rock here, not wall-smashing beats! I don't as yet even know how to further diagnose my issue. Were I able to, and fix it, I'd have no need to move away from mpd.

Yes, I want "bit perfect" playback. Why not? And yes, in my exact user case I don't need wide compatibility, as I don't stream, or use playlists, or etc. My music player is effectively a CD player: load album; play;stop. It's been doing exactly this for years with no issues, but now that I have this one (and it's the kind of noise that I suspect may ruin expensive speakers) I not only wish it to not occur, but I wish to ensure that it is unlikely to ever happen again.

archuser_9999 · 2024-10-10 16:48:03

okay, so now I'm just confused - let's leave alone the issue of the misbehaving mp3 file...

Further to above help and links, I've gone back again and made a couple more changes. My .asoundrc looks like this

pcm.!default {
        format S24_LE
        rate 44100
	type hw
	card 0
}

ctl.!default {
	type hw           
	card 0
}

(yes, I know - S24_LE. But why downsample the original file?) and the relevant section of my mpd.conf looks like this

# Audio Output ################################################################
audio_output {
	type			"alsa"
	name		"pcm.!default"
	device		"hw:0,0"
	auto_resample	"no"
	auto_format	"no"
	replay_gain_handler		"mixer"
	}

Now my log output gives me

Oct 10 18:23:49 Snazz mpd[1100]: libsamplerate: libsamplerate converter 'Fastest Sinc Interpolator'
Oct 10 18:23:49 Snazz mpd[1100]: vorbis: Xiph.Org libVorbis 1.3.7
Oct 10 18:23:49 Snazz mpd[1100]: opus: libopus 1.5.2
Oct 10 18:23:49 Snazz mpd[1100]: sndfile: libsndfile-1.2.2
Oct 10 18:23:49 Snazz mpd[1100]: hybrid_dsd: The Hybrid DSD decoder is disabled because it was not explicitly enabled
Oct 10 18:23:49 Snazz mpd[1100]: decoder: Decoder plugin 'wildmidi' is unavailable: configuration file does not exist: /etc/timidity/timidity.cfg
Oct 10 18:23:49 Snazz mpd[1100]: simple_db: reading DB
Oct 10 18:23:49 Snazz mpd[1100]: input: Input plugin 'qobuz' is not configured: No Qobuz app_id configured
Oct 10 18:23:49 Snazz mpd[1100]: curl: version 8.10.1
Oct 10 18:23:49 Snazz mpd[1100]: curl: with OpenSSL/3.3.2
Oct 10 18:23:49 Snazz mpd[1100]: state_file: Loading state file /home/alan/.config/mpd/mpd_state
Oct 10 18:23:49 Snazz mpd[1100]: inotify: initializing inotify
Oct 10 18:24:12 Snazz mpd[1100]: inotify: watching music directory
...

Oct 10 18:24:58 Snazz mpd[1100]: client: [0] process command "currentsong"
Oct 10 18:24:58 Snazz mpd[1100]: client: [0] command returned 0
Oct 10 18:24:58 Snazz mpd[1100]: mad: detected LAME version 3.100 ("LAME3.100")
Oct 10 18:24:58 Snazz mpd[1100]: mad: LAME peak found: 0
Oct 10 18:24:58 Snazz mpd[1100]: mad: encoder delay is 576, encoder padding is 648
Oct 10 18:24:58 Snazz mpd[1100]: decoder: audio_format=44100:24:2, seekable=true
Oct 10 18:24:58 Snazz mpd[1100]: client: [0] process command "status"
Oct 10 18:24:58 Snazz mpd[1100]: alsa_output: opened hw:0,0 type=HW
Oct 10 18:24:58 Snazz mpd[1100]: alsa_output: buffer: size=32..524288 time=725..11888617
Oct 10 18:24:58 Snazz mpd[1100]: alsa_output: period: size=16..262144 time=362..5944309
Oct 10 18:24:58 Snazz mpd[1100]: alsa_output: default period_time = buffer_time/4 = 500000/4 = 125000
Oct 10 18:24:58 Snazz mpd[1100]: alsa_output: format=S32_LE (Signed 32 bit Little Endian)
Oct 10 18:24:58 Snazz mpd[1100]: alsa_output: buffer_size=22050 period_size=4410
Oct 10 18:24:58 Snazz mpd[1100]: output: opened "pcm.!default" (alsa) audio_format=44100:32:2
Oct 10 18:24:58 Snazz mpd[1100]: output: converting in=44100:24:2 -> f=44100:24:2 -> out=44100:32:2
Oct 10 18:24:58 Snazz mpd[1100]: client: [0] command returned 0
Oct 10 18:24:58 Snazz mpd[1100]: client: [0] process command "replay_gain_status"
Oct 10 18:24:58 Snazz mpd[1100]: client: [0] command returned 0
Oct 10 18:24:58 Snazz mpd[1100]: client: [1] process command "idle"
Oct 10 18:24:58 Snazz mpd[1100]: client: [1] command returned 1
Oct 10 18:24:58 Snazz mpd[1100]: client: [0] process command "status"
Oct 10 18:24:58 Snazz mpd[1100]: client: [0] command returned 0
Oct 10 18:24:58 Snazz mpd[1100]: client: [0] process command "replay_gain_status"
Oct 10 18:24:58 Snazz mpd[1100]: client: [0] command returned 0
Oct 10 18:24:58 Snazz mpd[1100]: client: [1] process command "idle"
Oct 10 18:24:58 Snazz mpd[1100]: client: [1] command returned 1
Oct 10 18:24:59 Snazz mpd[1100]: update: spawned thread for update job id 1
Oct 10 18:24:59 Snazz mpd[1100]: inotify: updating 'Chris Stapleton/Higher' job=1
Oct 10 18:24:59 Snazz mpd[1100]: update: starting: Chris Stapleton/Higher
Oct 10 18:24:59 Snazz mpd[1100]: client: [0] process command "stats"
Oct 10 18:24:59 Snazz mpd[1100]: client: [0] command returned 0
Oct 10 18:24:59 Snazz mpd[1100]: client: [0] process command "status"
Oct 10 18:24:59 Snazz mpd[1100]: client: [0] command returned 0
Oct 10 18:24:59 Snazz mpd[1100]: client: [1] process command "idle"

Why do both

Oct 10 18:24:58 Snazz mpd[1100]: alsa_output: opened hw:0,0 type=HW

and

Oct 10 18:24:58 Snazz mpd[1100]: output: opened "pcm.!default" (alsa) audio_format=44100:32:2

exist? Why is there still

Oct 10 18:24:58 Snazz mpd[1100]: output: converting in=44100:24:2 -> f=44100:24:2 -> out=44100:32:2

an output conversion from 24 bit to 32 bit? I thought I'd set "no" resampling in my config?? Clearly I must not be doing something correctly but I have no idea what it is?

Also... from above log output, if I'm not requiring any resampling, it's still not clear to me at all how or where I get to disable the mpd internal plugins for libsamplerate converter. I did read that section of the docs, and indeed there are other converters available, but I didn't see a) how to set this correctly (every config I tried simply threw an error) and b) there's no option for "none" (if I don't need any conversion, why do I need a converter?)

V1del · 2024-10-10 17:10:32

Try disabling the replay_gain_handler by setting it to "none".

The "name" attribute is for visual purposes and used internally by mpd you can set that to whatever you want. If you want to force MPD to use your configured ALSA config you set

device "default"

("!pcm.default" is an alsa config identifier, it will reconfigure the device other applications "see" as the "default")

FWIW is it possible to share the affected file? Or do you have that issue with everything?

Last edited by V1del (2024-10-10 17:12:04)

archuser_9999 · 2024-10-10 17:23:52

thank you for trying to help.

I followed your suggestions, and rather than repost the same output, suffice to say nothing at all has changed.

mpd still differentiates between <alsa_output> and <output> (being my alsa config). Still insists on upsampling it to 32 bit.

I will happily share the file if it might help me diagnose this issue. But before I might, I am aware that this is a purchased mp3 file by a mainstream artist. And as such (not trying to be daft about this, am thinking about ensuring the forum doesn't break any rules) I have purchased the right to play the file, but I do not own the music or the copyright.

As before, I have a problem with ONLY this song. Nothing else. Have been using this setup for years without issue. At present I have no idea quite why this happens, but would love to know. The song in question is from the last Chris Stapleton album Higher, and is called "Loving You On My Mind". Were you to set up mpd using my config, and with no Pulse, Jack, Pipewire etc. just use the .asoundrc as posted, I'm guessing you'll have the same issue? If not well! then there's a way to maybe investigate this issue?

So yes, happy to attach the file here, as long as doing so isn't breaking the wrong rules - as technically I'd be making available a copyrighted song.

archuser_9999 · 2024-10-18 17:33:10

Update:

At something of a complete loss here. What I have done:

1: Reformatted and reinstalled to main partition. I had a few 'peculiar' things I couldn't sort, and after years of maintenance "it was time". So, starting with a shiny new install.
2: installed mpd and got basic audio output working
3: had to add a very basic .asoundrc to set internal sound card and NOT the attached midi keyboard as default sound device

defaults.pcm.card 1
defaults.ctl.card 1

4: no other mucking about or etc. just as plain "vanilla" as possible.

But... I STILL have this bizarre and (now) infuriating issue with the same mp3 file, but have no clue now where to look, what extra docs I should be reading, what utility or cmd I ought to be using to try to see why this is happening. Gave up on oscilloscopes.

I thought it might just be that I'm asking too much of such a basic setup, so I installed Pipewire and Wireplumber. All good, all set up correctly, but issue persists.

Please, does anybody have any ideas at all? Thing is, I daren't connect this audio out to my living room amp and speakers if this turns out to be a spike. I don't really want to dump Cantata just because of this, but at this stage I am stumped and mystified. I have zero clue about where to look next, or how to analyze this issue.

Head_on_a_Stick · 2024-10-18 20:39:03

archuser_9999 wrote:

what utility or cmd I ought to be using to try to see why this is happening. Gave up on oscilloscopes

You can use audacity to visualise waveforms.

archuser_9999 · 2024-10-19 15:44:01

I appreciate the response but feel like I'm going round in circles here.

To recap from several of my above posts:

the track looks fine! There's nothing I can see within the file itself. Furthermore, this ONLY happens when replaying with mpd. If I use MPV or any other media player, I have no issue.

So, I am trying to discover HOW I find out what this issue is. Because it is an issue, not my imagination and not some misconfiguration.

archuser_9999 · 2024-10-20 15:13:53

solution was: explicitly disable every 'unused' input plugin, decoder plugin enabled by default. Set resampling to "soxr: very high". Bingo!

Phew

Arch Linux

#1 2024-10-10 10:23:59

[SOLVED]Audio routed through alsa, but why is there still resampling?

#2 2024-10-10 10:50:18

Re: [SOLVED]Audio routed through alsa, but why is there still resampling?

#3 2024-10-10 11:46:03

Re: [SOLVED]Audio routed through alsa, but why is there still resampling?

#4 2024-10-10 12:23:27

Re: [SOLVED]Audio routed through alsa, but why is there still resampling?

#5 2024-10-10 12:38:21

Re: [SOLVED]Audio routed through alsa, but why is there still resampling?

#6 2024-10-10 12:44:32

Re: [SOLVED]Audio routed through alsa, but why is there still resampling?

#7 2024-10-10 12:50:36

Re: [SOLVED]Audio routed through alsa, but why is there still resampling?

#8 2024-10-10 13:10:37

Re: [SOLVED]Audio routed through alsa, but why is there still resampling?

#9 2024-10-10 13:25:19

Re: [SOLVED]Audio routed through alsa, but why is there still resampling?

#10 2024-10-10 14:40:25

Re: [SOLVED]Audio routed through alsa, but why is there still resampling?

#11 2024-10-10 14:55:16

Re: [SOLVED]Audio routed through alsa, but why is there still resampling?

#12 2024-10-10 16:48:03

Re: [SOLVED]Audio routed through alsa, but why is there still resampling?

#13 2024-10-10 17:10:32

Re: [SOLVED]Audio routed through alsa, but why is there still resampling?

#14 2024-10-10 17:23:52

Re: [SOLVED]Audio routed through alsa, but why is there still resampling?

#15 2024-10-18 17:33:10

Re: [SOLVED]Audio routed through alsa, but why is there still resampling?

#16 2024-10-18 20:39:03

Re: [SOLVED]Audio routed through alsa, but why is there still resampling?

#17 2024-10-19 15:44:01

Re: [SOLVED]Audio routed through alsa, but why is there still resampling?

#18 2024-10-20 15:13:53

Re: [SOLVED]Audio routed through alsa, but why is there still resampling?

Board footer