search

milkytracker / MilkyTracker

An FT2 compatible music tracker
http://milkytracker.github.io/
Other
1.72k stars 162 forks source link

OSX: Milkytracker fails to comply with system sample-rate #77

Open Deltafire opened 7 years ago

Deltafire commented 7 years ago

(reported on Facebook)

This may affect other platforms too, but this is how I think it's affecting OSX:

User connects an audio device (in this instance Bluetooth headphones) that operate on a non-standard sample rate (ie, 33khz). The Milkytracker config drop-down only allows 22kHz or 44kHz, so one setting plays too fast and the other too slow.

Milkytracker should try to adapt to the system mandated sample-rate.

dwhinham commented 7 years ago

Current logic of the CoreAudio driver:

  1. Get Device Format (samplerate, stereo/mono etc) from the device we want to open
  2. Does the samplerate match what we want?
    1. NO:
      1. Tell CoreAudio to set it to what we want. CoreAudio accepts the request regardless of whether it's possible.
      2. If the device happens to support it - we get it
      3. If the device doesn't support it - we get some other value - maybe the first one on the list in Audio MIDI Setup. Either way, it doesn't match our mixer.
      4. Continue to step 3.
        1. YES:
      5. Continue to step 3
  3. Get frame size properties etc and open device.

What should probably happen:

  1. Get Device Format (samplerate, stereo/mono etc) from the device we want to open
  2. Does the samplerate match what we want?
    1. NO:
      1. Ask CoreAudio: Does the device support what we want?
      2. YES:
        1. Tell CoreAudio to set it to what we want. CoreAudio accepts the request and sets the samplerate.
        2. Continue to step 3.
      3. NO:
        1. Throw the "Sound driver init failed" error.
          1. YES:
      4. Continue to step 3
  3. Get frame size properties etc and open device.

I've just attached my own BT headphones and can reproduce the behaviour from the Facebook thread - I can probably get this fixed without too much effort.

A related problem: if MT currently has a device open, and the samplerate is changed from within Audio MIDI Setup, MT speeds up or slows down because it has no mechanism to listen to/respond to changes. This can happen if MT has the "Default device" open and the user plugs in a USB sound card or some headphones, because the "Default device" may switch devices and therefore formats.

This one might need more code to handle, as we would need to listen for these events, and then respond to them somehow - either reconfiguring the mixer, or shutting it down and restarting it. Other audio systems like SDL probably do their own internal resampling so mismatches like this may be hidden (albeit with the undesirable effect of having all your audio data resampled which reduces quality).

CorvusCorax commented 7 years ago

It might actually be really neat if Milkytracker could support arbitrary sampling rates, it could then a) adapt to the requirements of a non-standard sampling rate output device b) allow custom exports - example:

I create a custom instrument in MilkyTracker, using the signal generators and some envelope effects in the instrument editor. I then make a short track that plays one note with this instruments with additional pattern effects (for example volume or pitch slide, or playing it multiple times for a nice C minor)

I want to then export this pattern as a wav to import it again as a new instrument/sample into a MOD file (which doesn't support the advanced instrument features) But to be able to reimport that wav as a sample, however I need to export it with a sampling rate of 8363 Hz in order to have it at 0 finetune and play nice together with my other samples.

Since Milkytracker does only support exporting at fixed presets (none of which is 8363 Hz) I need to either resample the exported wav (which looses quality) or transpose the pattern (and sample finetune) before export, so it compensates for the rate mismatch.

There are actually some MOD players out there which completely ignore sample finetune, so making a track with finetune 0 improves compatibility.

This probably should be its own feature request though.

Deltafire commented 7 years ago

Dale: Does 7ea3f18 fix this issue?

dwhinham commented 7 years ago

For my own (cheap) BT headphones and regular wired headphones, it improved stuff, but when the original reporter [well, the one I was talking to, anyway] tested it they said it actually made things "worse" for his particular Bluetooth headphones, which I don't have access to.

It's been a while since I looked at this and it probably needs further testing with more configurations. I don't really have time at the moment though, I'm afraid.