dev builds
themes manual
device status forums
mailing lists
IRC bugs
dev guide

Rockbox mail archive

Subject: Re: FS#11232: software mixer

Re: FS#11232: software mixer

From: Jeff Goode <>
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.

Received on 2010-05-02

Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy