Thanks for working on this Sean,

I agree the only real solution is to switch to having the engine master
produce sound in a thread and push samples into separate FIFOs, one per
soundcard. That FIFO would then be rate-adjusted so that it always matches
the master out's consumption.

What you did seems like a good workaround for now -- only trigger the
EngineMaster on the master-out soundcard's callback. That way the master
will never skip or repeat a buffer. People can deal with skips in their
headphones for now. Unfortunately this won't help people using
external-mixer-mode with 2 soundcards though.

RJ

On Tue, Nov 23, 2010 at 9:26 AM, Sean M. Pappalardo - D.J. Pegasus <
[email protected]> wrote:

> Hello again, everyone.
>
> In working more on the fixes_soundcardSync branch, I've been able to at
> least get it to lock to the clock of the sound card used for the master
> output (or the last direct deck output if a master output is not
> selected.) This solves the main problem I was having (skips & pops on
> the main output,) but over the past few days I've been trying to get all
> of the cards to stop skipping/repeating buffers.
>
> The core problem is this: Mixxx allows a card to lag/lead the reference
> card up to the latency period. Once that is reached, the card will
> either drop or repeat an entire sound buffer (drop if it's slower than
> the reference card, repeat if faster.) There's currently no way to
> adjust the buffer size for each card or callback.
>
> I've been trying to use a new SoundTouch instance to rate-adjust
> (pitch-shift) the sound buffer for each card with respect to the
> reference card such that if the current card drops or repeats a buffer,
> the audio will still sound correct. I recently realized that this is
> reasonable only if the reference card is faster than all the others,
> because catching up is just a matter of playing each buffer faster. But
> slowing down is not possible since the code currently only generates a
> new buffer when the reference card requests one. If the current card
> runs out of buffer before the reference one requests a new one, it's
> forced to play silence or repeat the last buffer until it's within a
> latency period of the reference card. Needless to say, that sounds
> horrific! I've committed the current state of the code to the branch
> incase anyone wants to try it out. (Note that enabling only a single
> sound card will skip all of the SoundTouch code and it'll work as it
> does in trunk.)
>
> So I'm afraid solving this completely and correctly will depend on
> implementing the master engine timer idea RJ had been talking about,
> wherein the engine will process buffers for the various output buses on
> its own clock instead of being tied to any sound card. The each sound
> card can request whatever size buffer it needs to keep pace with the
> reference sample rate, rate-adjusted as well if needed.
>
> That said, I'm requesting merging r2549 of the fixes_soundcardSync
> branch into trunk in time for v1.9.0 since it at least fixes issues on
> the master output with minimal code changes.
>
> Let me know your thoughts.
>
> Sincerely,
> Sean M. Pappalardo
> "D.J. Pegasus"
> Mixxx Developer - Controller Specialist
>
>
> ------------------------------------------------------------------------------
> Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
> Tap into the largest installed PC base & get more eyes on your game by
> optimizing for Intel(R) Graphics Technology. Get started today with the
> Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
> http://p.sf.net/sfu/intelisp-dev2dev
> _______________________________________________
> Mixxx-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/mixxx-devel
>
------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
_______________________________________________
Mixxx-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mixxx-devel

Reply via email to