Adjustable headphone latency

[Albert Santoni]

As suggested by Pieter Palmers:

feature request: add variable delay to the headphones output and express it in meters, not samples
allow the latency of the headphones path to be matched with the monitor or even the main FOH

This would be useful because if you don't have a pair of monitors and you're playing at a big club, you'll still be able to beatmatch with your headphones + the club speakers...

[Sean M. Pappalardo (pegasus-renegadetech)]

For reference, the speed of sound is 343 m/s or (1125 ft/s) according to Wikipedia: http://en.wikipedia.org/wiki/Speed_of_sound

So the formula to be implemented is: delay value = distance to compensate in meters (or feet) / 343 (or 1125)

This should be trivial to implement, no?

[Albert Santoni (gamegod)]

>From: Pegasus <email address hidden>
>Reply-To: Bug 225966 <email address hidden>
>To: <email address hidden>
>Subject: [Bug 225966] Re: Adjustable headphone latency
>Date: Fri, 07 Nov 2008 16:43:03 -0000
>
>For reference, the speed of sound is 343 m/s or (1125 ft/s) according to
>Wikipedia: http://en.wikipedia.org/wiki/Speed_of_sound
>
>So the formula to be implemented is: delay value = distance to
>compensate in meters (or feet) / 343 (or 1125)
>
>This should be trivial to implement, no?
>

Adam and I are physicists, so it's not the math that's the problem.
Implementing a GUI and all that other overhead is the hard part, and right
now we've higher priority tasks that we're working on. :)

This might be a fun task for someone who's new to the codebase though...

[Owen Williams (ywwg)]

Is this bug still up for grabs? I had a situation recently where this feature would have been useful, and creating a delaying sound buffer should be relatively trivial.

I would create a new EngineChannel that the headphone buffer would be passed through before it gets outputted. It would take in a buffer of (undelayed) audio from enginemaster and throw it into its own circular buffer with the right amount of delay. then I'd copy from the circular buffer to the output buffer based on the delay size. In case of underrun, I'd just spit out silence.

Maximum delay would be based on MAX_BUFFER_LEN

[Sean M. Pappalardo (pegasus-renegadetech)]

Yep, grab it man. Go nuts! Just make sure to add a setting in the preferences to adjust the amount of delay.

[Owen Williams (ywwg)]

Here's a first-pass patch. I just implemented it as a slider, not as "feet" or "milliseconds" or "samples" of delay. If I want to adjust the delay, I'm going to do it by ear, not with a measuring tape.

Delay is not saved across sessions, it always starts at zero.

I made use of an existing class called "enginedelay.cpp" which is going completely unused. So I renamed it to enginepfldelay and put it to work.

[Owen Williams (ywwg)]

I'll get this whipped into shape for 1.10.1 -- I don't want to try out a new feature like this for 1.10.

[RJ Skerry-Ryan (rryan)]

It's gotta be 1.11.0 since new features only go in major releases, but hopefully 1.11 is early 2012 so it won't be too long.

[RJ Skerry-Ryan (rryan)]

Thanks Owen -- I like this but I think it needs to support units first instead of a hard-coded delay in EngineDelay. I'm pushing it to 1.11.1 for now but feel free to move it back if you plan to make progress soon.

RE: Renaming from EngineDelay to EnginePflDelay I think it should stay as EngineDelay so that it stays reusable. The ConfigKey for the delay pot could be passed in through the constructor or something.

[RJ Skerry-Ryan (rryan)]

(Ideally the units would be seconds. I hear what you're saying about doing it by ear but it should have the units too)

[Daniel Schürmann (daschuer)]

I will try to reanimate this patch while working on the two soundcard issues Bug #1203249

[RJ Skerry-Ryan (rryan)]

IMO this would violate the feature freeze. Please focus on Bug #1203249 only. Adding a user-configurable PFL delay is not within the scope of that bug.

[RJ Skerry-Ryan (rryan)]

(even if the implementation of that fix makes this bug easier to fix)

[RJ Skerry-Ryan (rryan)]

On second thought, if the change is tiny then this should be fine to include with your fix to Bug #1203249. There will surely be a bunch of low-risk areas we want to violate the freeze for tiny fixes so exceptions are fine.

[Daniel Schürmann (daschuer)]

The fix lives already in https://github.com/daschuer/mixxx/tree/two_soundcards I can do a merge request if you like. But I will not actually merge if before the two sound cards issue is fixed. I like to have this fit to the whole.

[Swiftb0y (swiftb0y)]

Mixxx now uses GitHub for bug tracking. This bug has been migrated to:
https://github.com/mixxxdj/mixxx/issues/4955