Can anyone on our side confirm this microphone bug is fixed?
---------- Forwarded message ---------- From: Alan Horstmann <gine...@aspect135.co.uk> Date: Mon, Nov 18, 2013 at 8:48 AM Subject: Re: [Portaudio] Recording devices opened mono still sending stereo causing corrupt audio To: Portaudio Mailing List <portau...@music.columbia.edu> Hi Ross, On Sunday 17 November 2013 18:54, Ross Bencina wrote: > Sorry I lost track of this. Well, I was just waiting for confirmation from the Mixxx guys - the patch is on their bug-tracker but it seems they're all busy! Hopefully that will come some time. > Please go ahead and apply the current fix if you haven't already. You, > Phil and I have checked it and that seems as good as we're likely to get > at the moment. Once you've done that I'll tweak the comments as I noted > in my earlier message. Done. > As far as other potential refactorings: > > The buffers always need to be dynamically registered of course, but > perhaps you're right that the other info can be set at bp init time. Out-of-my-depth talking here, but is it actually necessary to set the buffers up separately before the processing (other than a single pointer to the start of the area)? For example are the channels ever able to be non-contiguous areas? It looks like the _SetxxxChannels() funcs do the same sort of adjustments based on interleaving, num channels, format size, that are used again later in the (Non)AdaptingProcess() to index various pointers in the data buffers. However, that is a bit of a side issue. > From memory I wanted to keep the information about dynamic buffers with > the buffers (hence passing stride at each callback rather than at bp > initialization time). I think you can argue it both ways: either it's > better to init everything up front, or not. My preference for the latter > was that it makes it harder for clients to make bugs -- since the info > about the buffers is registered at the same time as the buffers. I could see that intent, but the buffer data can't be used without also knowing other things, such as format and interleaving (ie it does not carry a full set of data). And different channels can't have different strides, so most of the values are duplications, and the processing would break if they differed, surely? Can't the 'pre-processing' stage work all this out from the params of the data?? Just throwing out things that are not carefully thought through... thinking along the lines of an _init() to set all the stream parameters into the bp (perhaps struct for each direction) called once for each openStream(), a _begin() or similar to set up each block of data prior to processing (and anything else), and actual _process() to do the job. But it is just 'arm-waving'! > That said, clearly the buffer processor has achieved "barely > maintainable" status and we probably should consider some clarifying > improvements. OTOH it is well tested and aside from the currently > discussed regression it hasn't exhibited any other problems. > > My gut feeling would be that if you think that all the host APIs can be > significantly simplified by tweaking the bp interface then we should > consider it, but if it's just for the sake of an internal refactoring > it's probably not a high enough priority to put energy into (compared to > all the already prioritised milestones/features). Those are very much my concerns - if it works as-is, maybe time is better spent elsewhere rather than break everything...but sometimes it is futile to resist the creative processes... Regards Alan _______________________________________________ Portaudio mailing list portau...@music.columbia.edu http://music.columbia.edu/mailman/listinfo/portaudio -- Albert Santoni Developer, Mixxx http://www.mixxx.org http://www.oscillicious.com ------------------------------------------------------------------------------ Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk _______________________________________________ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mixxx-devel
