|
Rockbox mail archiveSubject: Re: FS#11232: software mixerRe: FS#11232: software mixer
From: Jeff Goode <jeffg7_at_gmail.com>
Date: Sun, 02 May 2010 14:11:13 -0400 On 5/2/2010 14:03, Jeff Goode wrote: > On 5/2/2010 04:44, Jens Arnold wrote: >> On 01.05.2010, Jeff Goode wrote: >> >>> I'd like to know if there's some way to force SDL to behave >>> like a target, with a very small FIFO buffer rather than >>> its own large playback buffer, or at least not always >>> insist on its being full. Ideas? >> Perhaps just make the mix buffer larger for the sim? >> >> I have no real idea how to get around this while keeping SDL >> (and hence portability). > I think you're right about this and I'm going to give that a try > next. The sim audio driver still won't "DMA" like a target but at > least it ought to fill the buffer as SDL expects. Latency will > skyrocket though. Instead of 23 ms tops it'll be more like 250 ms. I > guess this isn't a problem as long as we're just using the sim to test > code, but it might if we're going to use it as a basis for > Rockbox-as-app. In that instance, the Rockbox mixer code would have > to be thrown out in favor of SDL mixer or some other library function. I just thought of another implication. If the Rockbox mixer has to be disabled later for the sim or Rockbox-as-app in favor of a library function, that would imply that some of the mixer code (such as the mixer ISR callback) doesn't belong in pcmbuf, but lower down toward the driver level, perhaps in pcm.c. Code in pcmbuf really ought not be target specific. Actually, neither should pcm.c but it's closer to the hardware level. I'm a bit conflicted here. Either way it's bloody mess. Jeff Received on 2010-05-02 Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy |