From: Chris B. <ch...@cn...> - 2011-02-22 15:20:00
|
Opps, hit send to fast. More below: On Tue, Feb 22, 2011 at 9:09 AM, Chris Bagwell <ch...@cn...> wrote: > 2011/2/22 Jan Stary <ha...@st...>: >> >> Now, playing the file with sox does _not_ crash, but the playback sounds >> much 'faster' than it should. I don't think it's simple multiple, >> as for example playing a 60s file takes about 8s: >> What does it sound like? Does it sound super fast and high pitch (sample rate issue going from 48000 down to 41100) or does it sound choppy like parts of audio is being discarded (samples being discarded from partial buffers)? I think its the later and I think I see a bug in my new code. Can you edit coreaudio.c around line 53: ac->buf_offset = 0; should instead be: ac->buf_offset -= len; This will stop discarding data when OS X driver is giving us partially empty buffers (which seems to be source of those segfaults since we were expected only full buffers). Its probably something SoX is doing to cause the partial buffers being filled... so probably the callback needs to never process incoming data until its received a full buffers worth of data. I'll work on that update next... but I think above change will help prove if its even worth improving. >> >> And again, with headphones plugged in, it plays just fine, >> which puzzles me the most. >> Yes, there is some sort of per-device buffer management that is really confusing here. Chris |