My empeg "pops" at startup, when voladj initializes its values.

It seems to happen at the moment when Frank's IOCTL utility sends it the values, although it also happens on a regular "default" startup of voladj, without using ioctl.

This has been happening since the very first version of Voladj, and I've brought it up before, although no one seemed to know what to do.

Does anyone else who uses Voladj get this "pop"? Can someone besides me reproduce it?

On the home outputs, it's very quiet (but it is there, I can hear it if I pipe it though my sound card and turn up the volume). And I imagine on some car outputs it might be quiet too. But my car's got some pretty loud amps and very efficient speakers, so it's very loud, enough to make my wife complain vocally about it if she's in the car at boot-up time.

I seem to recall that it happened on the Mk1 as well, but I'm not sure.

What could be causing this? Can anyone peek at it and see if it's something that could be changed in the Voladj code?

___________
Tony Fabris

It is definitely possible to get a pop when you use the ioctl if the current output sample is not a 0 (zero). If it is a zero, then I don't think you should get a pop. However, I expect that you wouldn't be able to hear music when you use the ioctl, so you should have a nice zero sample. Either the music has not started playing yet, or it has stopped playing from before.

I certainly can't hear any noise at all with the empeg volume cranked down, and the speakers cranked up.

Does it pop when you have the empeg volume turned right down? Is it relative to the empeg volume,
or independent?

Richard.

Does it pop when you have the empeg volume turned right down? Is it relative to the empeg volume, or independent?

Hmm, I don't know. It's at boot-up, so there's no "volume" that I know about. It does seem to be intermittent, so maybe it's related to whatever volume the unit was set to at last powerdown. I will check.

And as far as the "0 sample", it's not playing anything at all yet, it was just starting to boot. How could it have anything but a 0 sample?

Note that I think this only happens when Voladj intitializes at boot time. If I do it from selecting "quit" on the player software and dropping to the shell (or a shell script) and invoking ioctl, I don't think I get the pop. I think it only happens at boot. And it happens even if I don't use ioctl, it happens if all I've done is install the Voladj kernel.

___________
Tony Fabris

I really don't know about this. As far as I can see, as long as nobody is playing music, then you shouldn't get any extra pops when initialising the voladj stuff. I haven't re-analysed in detail what happens when you start playing music after initialising it, but it should be OK too. I thought you were getting it when you called ioctl() after exiting the player, but if not, then I'll have to play with rebooting my player and see if I can duplicate it. I certainly couldn't duplicate it by stopping the player and calling ioctl().

Richard.

Right. It happens at boot time only. I think it happens becuase the audio circuitry is in a different state at boot time than when you exit the player software.

The reason I mentioned ioctl is not because I thought it was the cause. It's because, if I invoke ioctl after a keypress from my shell script at bootup, that's the "moment in time" when the pop happens.

It might not have anything to do with ioctl, it's just one of the things that happens within milliseconds after ioctl gets invoked. But only at boot time.

___________
Tony Fabris

I also get the pop as well, but it's not as noticeable to me. Same situation as Tony, only on boot. One thing I remember from my MK1 is that volume is at 0db before the player starts, at least it was. I found that out the hard way with my old startup sound. (Embarrassing story withheld from this thread)

One thing I remember from my MK1 is that volume is at 0db before the player starts, at least it was.

Ah, yeah, right. I remember that. Makes sense. Richard?

___________
Tony Fabris

I had a play with it, and have determined:

- The volume level at shutdown time doesn't seem to affect the pop. I can crank it down to zero, remove and reinsert the player, and the same pop happens during the boot.

- It isn't related to whether there was a track playing at shutdown time. I got the same pop even at "end of playlist".

Something occurred to me:

What if this isn't even something Voladj is doing actively? Perhaps it's more like this:

Somewhere in the player startup routines, it resets the DSP, which causes a pop. Or something like that. Now, normally, the player's got its outputs muted when it does that. But something about your altered kernel causes the volume to be turned up at that time instead of muted. You didn't make the pop, you just allowed me to hear it.

The only reason I hear it when I select the ioctl with voladj is because that's instantaneous, and the player startup routines come right after that.

What do you think of that theory? Hare-brained?

Wait... no, that can't quite be it. Because I've got that "getkey" thing running as the very next item in my init script. It waits a few seconds on a blank screen before launching the player. The pop happens after I invoke ioctl and before that getkey thing runs. There's something happening at that moment which I'm not understanding. Hmmm....

___________
Tony Fabris

Maybe it's actually when the player starts up, and sets the volume??? No, that can't be it either.

I was just trying it here on my desk. I get a pop when I actually push the power into the back of the empeg, and I also get a pop when the Empeg logo first appears, but that's all I can hear. I get these pops regardless of whether I'm using a voladj kernel or not.

I'll try whacking a few different init scripts next (at the moment all my customisation is in /etc/profile, slower, but less memory intensive).

Richard.

*BUMP*

Anyone get a chance to look at this any closer?

Can anyone else confirm that it happens on their equipment when they use the Voladj kernel?

This bug reminds me of the old days on the Commodore 64. The C-64 had a set of registers for controlling its SID (sound interface device) chip.

To initialize the chip, you were supposed to fill those registers with zero bytes. But some programmers took this literally, and did exactly that, in sequence. But they forgot to mute the volume first. So there were many programs/games which would "pop" at startup every time you ran them. As the bytes got written to the registers, you'd get random bits of noise as the chip got told to do strange and random things for a millisecond or so.

A properly-written program would turn the volume all the way down first, reset the registers (except the volume register), then turn the volume back up again.

Is it possible something similar is happening in this kernel?

___________
Tony Fabris

One other thing. This might help narrow down the location in the code where it happens. I might have mentioned this before, but I'll repeat it for clarity:

I can make this happen with only the kernel installed (no custom init), the pop happens sometime while my custom logo is up on the screen.

But when I do have a custom init, it goes like this:

1) Boots and mounts the drives.

2) Presents a menu allowing me to choose whether voladj is off or on.

3) Depending on what I pressed, it sends the ioctl message to either activate or deactivate voladj.

4) Pauses for about 3-5 seconds and waits for a "q" on the serial port.

5) If no "q" on the serial port, then launch the player.

Okay, I get the pop at step 3. So it happens somewhere in the code that responds to the ioctl message. It's not related to the player, since the player software hasn't started yet, and won't start for the next few seconds.

But I also get the pop if I don't do an ioctl at all with no custom init. So it happens somewhere in the code that gets called by the kernel as the player is booting.

So what kernel code is called both during the regular boot process and when the ioctl message is received?



___________
Tony Fabris

This is strange. All that happens when you do the ioctl is that the parameters for the volume adjustment get set. It doesn't actually touch the audio device at all. Now, changing these parameters could make a pop if there was music playing, but there should no buffers containing music.

I don't know why it's happening.

I will have to try putting a custom init in place on my player and see how much I can duplicate this behaviour. You don't get this behaviour with the standard kernel, right?

Richard.

Right, I never get a pop with the standard kernel. I always get the pop with Voladj (whether it's by itself or if I'm using ioctl to set the parameters).

And the pop doesn't happen if I "quit" from the player and run ioctl, it only happens if I do the ioctl as part of an init script around boot time.

The character of the pop changes from time to time. It's louder some times than others. And I'm not certain of this, but I think it mostly comes out of the left channel. It might be ONLY out of the left channel, I'm not sure.

Perhaps it's a bit random data in the audio output buffer or something, and voladj is turning up the volume on it? I dunno.

I haven't used a kernel that you personally have compiled, I've only been using kernels that included your code. Maybe they've done something wrong?

___________
Tony Fabris

Now I'm just getting more confused.

It seems that the first time I open /dev/dsp I get a tiny click out of the left speaker, when my empeg is sitting on my desk. This happens if I use Frank's voladj or my old selecter. The actual ioctl call does not make a click, it's just the open(). But I don't get this click when the player starts up, or when I remove any stuff like this from my init script. But you said you DO get the click when you don't do anything special. I don't understand.

This is what happens when I boot:
- BIG pop when I push the power in the back
- Pretty big pop roughly when the kernel initialises the audio device
- Small (but definite) click when voladj or selecter opens the audio device

I think empeg_mixer_eq_apply() gets called when we open /dev/dsp. Maybe we should open /dev/mixer first, and set the volume to 0, and then open /dev/dsp??? I guess I can try that.

Richard.

I think empeg_mixer_eq_apply() gets called when we open /dev/dsp.

Whoa, wait a minute!

Don't you remember the other bug report about that?!?!

Heh... There is a bug report (long-standing) that you get a pop out of the amplifier whenever you switch the EQ from 4-channel mode to 2-channel mode.

Suppose it's related?

___________
Tony Fabris

It seems that the first time I open /dev/dsp I get a tiny click out of the left speaker, when my empeg is sitting on my desk.

Right, this is consistent with my experience. Left speaker only. The main difference is that my car amplifiers are hella powerful, so when this happens in the car, you're talking a serious amount of sound.

But that EQ thing is interesting, see my other post!

___________
Tony Fabris

Don't you remember the other bug report about that?!?!

Umm, no. Shows you how much I adjust my EQ, eh? :)

Anyway, I tried doing this before opening /dev/dsp:
mixerfd = open(MIXER_DEV, O_RDONLY);
muteflags = EMPEG_MIXER_FLAG_MUTE;
iores = ioctl(mixerfd, EMPEG_MIXER_WRITE_FLAGS, &muteflags) ;
(abridged version without error checking or #defines or anything)
and the sound went away. So if we stick something like that in Frank's voladj, you could be laughing. However, I still don't know about the pop you get when you don't do anything on boot.

Richard.

Well, if you can attach a copy of that modified voladj file (hopefully compiled so that it works with the new ioctl number in 1.03) to a BBS message, I can test it out and tell you how it goes.

___________
Tony Fabris

You can give this a try if you like. It should work with 1.03.

Richard.

Thanks! I'm throwing it on the player now.

I'm on the way out to see Jurassic Park 3 (opening night) and I'll report on how it worked when I get back.

___________
Tony Fabris

Heh, noticed right away...

That one leaves the player in a permanently muted state. As soon as that version of voladj is called, my player is silent. Heh....

Haven't tried it in the car to see if the pop is gone... hehe...

___________
Tony Fabris

Okay, here's where it stands:

- The muting ioctl utility you just posted FIXES the popping problem. There is no pop when I use this version.

- It permanently mutes the player when using the "home" outputs. After it's called, the home outputs are silent.

- It does not permanently mute the "car" outputs. Those work as expected. So in the car, I've now got what I want: No pop, and correct sound in the car. Actually, I haven't really checked to make sure that it's not muting just the fronts or just the rears or something. All I know is that in-home I get no sound, in-car, I get sound.

So, if we could get to the bottom of this home/car muting thing, we'd be golden.

Also...

From what you said, I am now doubting my previous statement where I said the pop happened without an ioctl. I realize that I haven't actually tested that assumption recently. I could be remembering it wrong. Doesn't matter, though, if we can fix the muting in the ioctl utility, I would be happy. I would re-publish my picker file with the new utility (along with source), and I would consider it "all done".

___________
Tony Fabris

Yeah, I was a little worried about this, but it worked fine on my Mk2 here, so I didn't bother unmuting! Mind you, I'm calling the original init at the end of my init shell script, so maybe it UNmutes it again.

Anyway, as a proof of concept it seems OK, so now we just have to make it so that it unmutes after opening /dev/dsp. Please find attached file.
Actually it would be better if it restored the original flags, but I can't be bothered right now.

I guess we could put a hack into empeg_mixer.c so that it always mutes the device before changing the EQ. But that wouldn't sound nice if you adjust the EQ while music is playing.

Richard.

Please find attached file.

Awesome. The new one is working great for me so far. I will update my publicly available picker file today.

Thanks!!!

Actually it would be better if it restored the original flags, but I can't be bothered right now.

I don't know the nitty gritty details of how it works, but your current coding method doesn't seem to have any ill effects on my system. Can anyone foresee a situation where failing to restore the flags would be a problem?

I guess we could put a hack into empeg_mixer.c so that it always mutes the device before changing the EQ. But that wouldn't sound nice if you adjust the EQ while music is playing.

The only time people reported a pop is when switching from 2-channel to 4-channel. I think you're referring to a global mute every time an EQ is changed. You're right, that would be annoying.

Empeg guys: Have you been paying attention? What about muting the the mixer only when switching between 2/4 channel? A brief mute is better than a pop. I don't think you'd get any support calls on it, because it would sound like "it's supposed to do that" when it happens. At least that's the way I'd interpret it if I got a brief mute in that situation.

___________
Tony Fabris