You can try removing the cable and squeezing the connectors with a pair of pliers. In effect "re-crimping" it better. See if that works.

Note: You have to do this carefully and in the right direction or else you'll just make it worse or smash the connector.

Ok, I've confirmed both bugs.

The popping I hadn't noticed before. I think that it is a symptom of the low Q value, pushing the band affected below DC. (In theory anything below Q=0.5 does that). This DC offset should be filtered out in the analog output stages (though AC coupling capacitors), so it shouldn't be a problem wrt to amps or speakers, but the transition between one DC level and another is causing a sharp transient that would get through the filter.

I originally had an explicit 0dB setting, with "Off" appearing as the setting below -6dB. Maybe we'll have to revert to this to remove the popping. (We need the "Off" setting so that users who don't want to use this feature don't get their eqs overloaded.)

The DC-mode non-restore I'll have to look into. I saw it in some of my test builds, but not in the patch that I eventually submitted to Mark. I never got a clear understanding as to what changed to fix it in my builds, and I can't see how Mark's changes would have affected it either...so. Debug time.

Thanks for the suggestion. I think I'll order a replacement cable anyway, and live with the intermittent problem until it arrives. At least I can test and debug.

In reply to:

---

The popping I hadn't noticed before. I think that it is a symptom of the low Q value, pushing the band affected below DC. (In theory anything below Q=0.5 does that). This DC offset should be filtered out in the analog output stages (though AC coupling capacitors), so it shouldn't be a problem wrt to amps or speakers, but the transition between one DC level and another is causing a sharp transient that would get through the filter

---

What about having the code always set the "0.0dB" values immediately before it sets the "[Off]" values, in empeg_mixer.c?

Hmmmm...that's definately worth a shot. I'll try it.

genixia,

Tone controls work for me on DC. I know the Empeg thinks it is in the car because I am unable to Restore Visuals with any combination of the Hijack "Restore..." functions enabled!

What additional info from my setup would be helpful?

Mk2a/10GB/Beta11/239
Equalizers set flat, volume fixed at -10 db

Lynn

Well, in a normal HTML environment, you'd use the named character entity ø (from this full list of name character entities), but since HTML stuff has been disabled here, then you just have to insert the 8-bit character manually and hope that whoever's viewing it is using the same character encoding (ISO-8859-1, etc.) that you are. Under MSWindows, the easiest way to find a character is to pull up the Windows Character Map (try Start->Programs->Accessories->System Tools) and find it in there.

The lengths some people will go to in order to increase their post count

What do you mean?

Thanks for the offer. I'm not sure what information is going to be useful at the moment though. I need to find a difference between those that get it restored, and those that don't.

Do you have any initial= lines in your config.ini ?
The only mechanism that I can suggest at the moment for tone control to not be initialised (assuming notify=1 has been set), would also stop initial= lines from working.

What about having the code always set the "0.0dB" values immediately before it sets the "[Off]" values, in empeg_mixer.c?

I've just realised what was bugging me about that idea. We'd need to do the same the other way too, ie from 'Off'->0db->value.

OOPS, I think I missed the original bug. I have the symptom of loosing the settings on reboot as well. Sorry for the false alarm.

Lynn

sounds easy enough. Does it "pop" both ways at present?

Okay, interesting behavior observed tonight with Hijack 241.

The first time I put it in the car, the bass WORKED at boot up, but the "restore visuals" did not, it sat at info:track.

When turned off the ignition, got gas, and turned it back on again (timeout is 5 seconds so it did fully reboot), the bass DID NOT WORK at boot up, but the "restore visuals" DID work.

Coincidence? Maybe....

Weird.

Ok, Anyone want to test this kernel binary? I've just spent 20 minutes sat in my car twiddling knobs, and I haven't experienced any pops or clicks while changing from -ve dB to Off to +dB and back again repeatedly.

There is a very small click if you use the top button to go directly from +/-6dB to Off, but the only way to deal with that is to code an automatic sequence to step down - and I think that would be a PITA to code and it might make the empeg sluggish while it went about it.

Oh, that test binary is based on Hijack 239 with the funky disco lighting.

The intermittent no-restore issue is still an issue, sadly. I am no closer to seeing a cause than I was earlier.

I use this very easy method - check out <url=http://www.asciitable.com/>asciitable</url> for the ASCII codes and then press and hold ALT, use the number pad to type the 3 digit number that corresponds to the character you want and then release ALT.

Voila! or should that be Vòila!

I found the situation where the bass doesn't work on player boot up.

Definition of "doesn't work": When you set it to be Bass +6db, and the player boots up, the bass is not boosted by +6db until you go into the bass adjustment menu and twiddle the knob. Then it suddenly pops to life.

When it doesn't work: In the car... If I yank the player out of the dashboard while it is playing, then re-insert it, it will boot up into "playback" mode. In other words, it begins playing tunes as soon as the boot process is finished. In this situation, the bass doesn't work.

When it DOES work: In the car... If I press and hold the top button so that the player goes into standby mode. Then I remove the player from the dash and re-insert it. The player boots into "standby" mode with the pulsing light. Then I turn the volume knob to wake up the player. In this case, the bass is properly boosted when it begins to play tunes after waking up from sleep mode.

To recap: Wake from standby: Works. Wake straight into play: Fails.

This is with Hijack 241.

Great news!

I'm going to go play with this a little. I'm guessing that there's a little bug in the notify code somewhere so that it doesn't notice the player starting after a yank.

I wouldn't have seen this often during testing - I have years of experience of being nice to linux boxes, and avoid hard restarts whenever possible. It's just a mindset, my brain is slowly coming around to the concept that the empeg doesn't care.

[edit]
That should really have said "computers" not "linux boxes". In my experience, linux boxes have been the most graceful in dealing with power outages.

More likely an issue with the player reseting the EQ after hijack sets the EQ.. stick some printk()'s into the code and see what the order is.

-ml

Bad news. I couldn't recreate Tony's findings. The bass failed to be applied regardless of the method of powerdown.

I can see that I'm going to have to make a hole in my glove compartment and bring the serial cable out....

Too bad, sorry. It's 100 percent reproduceable in my stated case. Note that I only tested it in the car.

Sounds like good news to me.. Now just jam some printk()'s into the mixer module to see what the sequence is.

Ok, I just threw a show_message("Tone Init", 2*HZ) in after the tone_init() in hijack_handle_display and the result is interesting:

On AC power, I always see my message pop up.
On DC power, I never see it pop up.

This suggests that tone_init is not getting called in DC mode. (It also suggests that any initial= line in config.ini doesn't get appplied.)

The only difference that I can see is that I get an "Info:Track" display momentarily after the visuals are loaded when in AC mode. This happens immediately before my message pops up, but I haven't seen it in DC mode.

Maybe this is related to DC visuals restore after all? I'm going to play with my DC restore settings in the car.

Ok, just tried this indoors with DC mode forced.

The serial port hangs on "Switching to" immediately after the player starts up. There appears to be no notify happening on the port after this point.

In AC mode, the next thing that happens is that khttpd and then kftpd start up...

Maybe it's time to look at ethernet/khttpd as possible culprits.

The serial port hang is due to the player software, which for some peculiar reason likes to change the baud rate on the serial port when on DC power. You can add lines to config.ini to prevent it:

[serial]
car_rate=115200 ; Set's default rate when on DC to 115kbps

And again, for the last time, stick some printk()'s into the kernel, in hijack.c and in the various routines of empeg_mixer.c, so that you can observe the exact sequence of things at startup.

Cheers

How do you think I discovered where to put the tone_init() in the first place? It's all good and well sticking the printks in the mixer code, but if they aren't getting out of the port...

Anyway, setting the car_rate to 115200 has changed things. I now get the behaviour that Tony wa reporting earlier - clean shutdown leads to restoration, but a yank doesn't. And now I can investigate the timings in DC mode.

Thanks.

Okay, good!

Yep, that's it.

In DC mode, after an unclean shutdown, three calls get made to set the eq. After a clean shutdown, or in AC mode, only 2 get made.

So I've got to find a way to wait on the third apply. Either that or put a timed loop in, or I could brute-force it once every ten seconds...(which would be a really ugly hack).

So the problem is on shutdown instead of on startup?