On Tue, Nov 23, 2010 at 6: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.
Correct, this was by-design, as I haven't ever come across a pair of soundcards myself personally where the drift is bad enough that this is a problem. Since Mixxx 1.6.0, I've read reports of maybe 3 users who might have been affected by this. If you're willing to put in the time, this is an interesting problem to solve though. > > 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. Yes, I believe you're right that we will need a "longer-lived buffer" than the callback buffers we have now. Implementing a ringbuffer and filling it from the engine is one way to do that. > 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. Well, each soundcard is going to consume samples at whatever rate it wants, we have no control over that. All we can do is make sure that when it consumes 44123 samples/second, those samples are read from our playback ringbuffer at 44100 samples/second and interpolated to 44123, which is being filled at 44100 samples/second. Maybe these are just implementation details though. I think saying that the consumption rate of each soundcard must be adjusted to match the reference samplerate (ie. what you said) is a good summary of the problem. :) > > 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. > The feature freeze has passed and this is a set of changes to the engine that could only benefit a small number of users, but break something for everyone if it's buggy. If you propose a merge, I'll take a look at it though. Thanks, Albert > 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
