Actually, take it back. I confused myself because my working code to get around the popping problem actually calls the mixer twice if the tone controls are set - Doh!

However, it looks like it is a race hazard in DC mode when it is not powering up into standby. (ie you didn't put it into standby first.)

Why the player holds off on setting the tone controls for this one case I don't know.

So at the moment:
AC: boot-> standby - player sets eq, then tone controls.
AC: boot-> active - ditto
DC: boot-> standby - ditto
DC: boot-> active - player delays, tone controls set, then player sets eq. Bad.

Ok, a time for a delay loop.

>Ok, a time for a delay loop.

Ahh.. pardon the obvious, but why not just hook the tone init into the first time the player software sets the EQ (ioctl() in empeg_display.c)?

-ml

Hmm...Don't think I've looked at that file yet!!

I'll do that if possible, although a quick and dirty loop just proved the theory.

Anyway, that's not obvious to me. Remember that I've only been coding C for a week

Errr.. oops. wrong file. I meant for you to look in empeg_mixer.c again.

Cheers

Hey, just watched Spy Kids...much better than I expected.

The ioctl modification is a good one. It cleans up some of the code nicely, and also removes that small eq synchronisation issue so that any time an eq is set by the player tone_init saves a fresh copy which is used by the 0dB code.

I'd looked very quickly at that idea when I first attacked the tone controls, but at the time I didn't feel comfortable changing anything that could break so much....When it comes to coding, I'm like a toddler wanting to touch everything, but still clumsy with my hands. I guess I should accept the fact that you wont accept badly broken code.

>I guess I should accept the fact that
>you wont accept badly broken code.

Not normally from others, but if wrote.. well..

Cheers