Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

sounds sped up (higher pitch) on linux #628

Open
runlow opened this issue Mar 3, 2023 · 4 comments
Open

sounds sped up (higher pitch) on linux #628

runlow opened this issue Mar 3, 2023 · 4 comments

Comments

@runlow
Copy link

runlow commented Mar 3, 2023

Steps to reproduce

  1. Install this package https://aur.archlinux.org/packages/xmp on archlinux
  2. make sure you're not running pulseaudio
  3. make sure you have a file with 644 permission in /etc/asound.conf with the same content as below
  4. Play some module: xmp DigSh.umx

Expected behaviour
Sounds the same as if playing it via mpv DigSh.umx (it uses libmodplug, no immediately apparent problem) or running the game the module is from and listening, or listening to it on youtube

Actual behaviour
It sounds sped up (too high pitch and too fast). I tried it on other umx files and other modules and it's doing the same thing.

Tried

  • setting a different frequency with xmp -f (makes no difference, it always defaults to 48000 Hz)
  • setting a different driver (only one I could get to work is the default alsa one, wasn't sure which driver list to choose from though, the program doesn't list the possible drivers)

Edit:
After more testing I realised that if I delete /etc/asound.conf ...which has the following content:

pcm.switch {
     type route;
     slave.pcm dmix;
     ttable.0.1 1;
     ttable.1.0 1;
}
pcm.!default {
    type asym
    playback.pcm "switch"
    capture.pcm "hw:0,1"
}

...when that file is removed then xmp works as expected!

I use that config file because the stereo channels seem to be the other way around on my sound card for whatever reason and everything seems to work well enough with it (except xmp). I understand now that the problem likely is with my setup, apologies.

I've noticed that when I get rid of that config file xmp sets the mixer to 44100 Hz as expected (rather than always to 48000 as before), the -f switch also works as expected now with that config gone.

Only thing is though that every program I use that produces sound seems to work OK even if I use that config file. I'll troubleshoot this further. Again sorry if this goes too far beyond the scope of the project.

Workarounds and possible solutions

  • first been using this command: xmp DigSh.umx -c|aplay -Dplug:default -f cd -q, it works almost perfect - correct pitch and speed (the "cd" format is 44100 Hz), except that there's about a second of delay when seeking or changing songs/subsongs
  • if I entirely comment out and save /etc/asound.conf specifically for xmp right before starting xmp the problem is avoided while programs already started with asound.conf work as they did before. In other words "hotswapping" the config before starting the program - incredibly ugly but it works
  • a much cleaner workaround than to previous is to set HOME=/tmp/fakehome specifically for one application and to create /tmp/fakehome/.asoundrc, it's the per-user asound.conf
@sezero
Copy link
Collaborator

sezero commented Mar 3, 2023

@AliceLR ?

@AliceLR
Copy link
Contributor

AliceLR commented Mar 3, 2023

This sounds like a bug in xmp-cli's ALSA driver to me. I can confirm I've had no issues like this with WinMM or PulseAudio, anyway. I will try to test and verify tomorrow.

@AliceLR
Copy link
Contributor

AliceLR commented Mar 3, 2023

I haven't been able to reproduce this but I notice the ALSA driver is ignoring a lot of function return values.

@runlow
Copy link
Author

runlow commented Mar 3, 2023

@AliceLR I think my list of steps to reproduce the issue missed having /etc/asound.conf with the specific settings I had (which could be written wrong, but like I said other programs don't seem to mind), edited the steps, also added a cleaner workaround I found today. When I don't use /etc/asound.conf everything works OK (except for the stereo channels being in wrong order but that's a hardware issue). I'll see if I can find out more.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants