I apologise if this is been asked already. I was just reading an extremely interesting post in another section fo the BBS regarding the possibility to introduce a delay between the right and the left channel, so that the overall output of the player could be better "centered" around the driver. I totally wish for something like that to be implemented in the player software, so I decided to mention it here. Maybe Mark you could help us with this before the empeg team implements such a feature, if they ever decide it is worthed to do so. So, here's my proposal I imagine a menu item in HiJack saying "left/right delay" and, once entered, the ability to set a value in ms in favour of one of the two channels. As simple as that (ehm... Not for me, don't get me worng. I have no clue about how to do anything like this )
Thank you in advance!!

This is on our wishlist, it may well get into hijack quicker though. It will only affect mp3s though, NOT radio or aux inputs.

Hugo

I owe you another beer if you happen to come to Italy. Not for the feature (for that you deserve much more) but for replying in few seconds just what I wanted to hear! I mean, what a great feeling, this is really like rubbing the lamp!
Now they're two, if I'm not getting confused with someone else of you empeg guys. I am sure, though, I already promised a beer to somebody there for the same reason

This could be implemented in the same code chunk as the VolAdj, I think. Perhaps Richard L. can be convinced to have a go at it for us all?

-ml

What shall we do to convince him? I'd be happy to email him or get in touch with him. Do you have any refs to his email?

Personally, L/R delay is the very first and only bad thing I noticed in my car installation, and that used to bother me so much. I believe I got used to it, but every time I move my head towards the center of the car I hear the sound as it is supposed to be, and I can really perceive a quite noticeable difference. I believe I am not the only one who would benefit from such a thing.

His email address is listed here: http://gecko.eric.net.au/~rjlov/searchentry.html

Ok, I emailed Richard

Well a delay option should be set for F/R as well don't you think??

How many times do we have to say this. You can't do a front/rear delay with the current car player hardware. Period.

How many times do we have to say this. You can't do a front/rear delay with the current car player hardware.

As often as the USB master/slave thingy.

As often as a new empeg owner joins this forum?

Sorry, I wasn't gonna search the FAQ for a casual reply to a similarly topiced thread..

-John M

Ok

I got a positive reply from Richard. He essentially said he will give a look at this since it sounds interesting to him as well, but he has little time and can't promise anything in terms of WHEN the new code will be released.
I asked him if I can post our emails here, so you all can see. If he agrees, I'll get back to you in this same thread.

I have started something built into Hijack. It almost goes right now. Give me a day or two to sort it out and I should have something quite useable for you guys to try out.

What sort of units would you guys want. I basically have two options :
1) Time delay
2) Distance (given the sound travels at roughly 333m/sec)

Or doesn't it really matter just as long as it is adjustable.

Personally, I find "time delay" easier to figure out. A value in ms would be perfect.

What sort of units would you guys want. I basically have two options :
1) Time delay
2) Distance (given the sound travels at roughly 333m/sec)

I would want both displayed on the screen simultaneously, in much the same way that Hijack allows you to adjust the temperature cutoff in C and F simultaneously. Twist the knob and look at both values change.

I agree. That's a better Idea.

Don't forget we need to be able to adjust the delay for both left and right hand drive vehicles (Right hand drive means the right channel needs the delay relative to the left, and Left hand drive means the opposite (left channel is delayed).

The UI could allow you to specify the delay as either:
A positive or negative value (time & distance) relative to a fixed channel (e.g. left) .

Or you input a positive delay value (by twiddling the knob or whatever) and then you indicate which channel the delay is relative to (left or right).

[and a nice touch would be that if the delay value goes negative, you could show the absolute 'delay' number but change the field showing whether the delay is relative to left or right channel to the other channel from the one currently in it).

Also, bear in mind that some folks use their empegs at home and in the car, so it would be nice (but essential to have settable delays for both home and in car use.

Also instead of using terms like 'Left hand drive' or 'Right hand drive' it might be better to allow the user to simply indicate if the listener is left or right of the (assumed) stereo centre line, and go from there. As terms like left hand drive have no meaning in a empeg used inside the house.

I think it should look like the player's "Balance" control, and it should be called "Listening Position Delay".

Centered, it would have no delay. As you moved it to the left or right, it would show a distance from center in both Meters and Feet. It would also show the delay as + or - a certain number of milliseconds.

That sounds fine to me.

Just like a regular Stereo balance control (with digital feedback of the delay).

Of course, I'm not doing the UI so I am not sure how easy it is to actually do the UI, or do the low-level delay feature.

Ok,

At the moment it only delays either the left or the right since there is no point in delaying both right? Basically it works just like a left right balance control. The UI displays the delay and whether it is being applied to the left or the right channel.

Also according to my calculations (333m/sec speed of sound) 1 meter is about 3ms away. So why do delay systems seem to have values in the tens of milliseconds (i.e. 10 metres = 30ms).

Do we need that much delay for time alignment or is say 2 - 3 metres enough for most people. I assume no one has a car wider than 3 metres.

This is almost how I picture it too. Default would be centered, rotating the knob CCW would delay the left side, rotating CW would delay the right side instead. Or bring it back to center for 0/0 All values could be negative, since you are delaying things. Only one speaker would need it at a time, too, since it's a relative deal between them. I think milliseconds is sufficient, and even 0-10 is about all you'd need in the car, if even that much.

Positive delays, is that kind of like going into the future? I could have a few uses for that

Oh, this is sweet! I was excited about possible GPS someday, but this is the highest wish on my list, I suppose you've read that already in the Wish List forum.

Don't foget that the speed of sound changes as your altitude goes higher.
Anyone here from Denver?

Also, if we alllow a minimum of 1ms 'delay' and increment in 1ms jumps then that allows 300mm or about 1 foot of delay per increment. You could halve that by allowing .5 of a ms increments - that would give a six inch granularity at sea level anyway - you would need 3 digits on the display - 1 for the units and one for the dot and one for the '5' or '0' of the increment. If you allowed for 20 ms delay then you would need 2 digits for the units rather than 1.

Even with .5 ms increments it would only require 40 'clicks' of the knob to go from full right to full left delay assuming a 10 ms 'in car' delay range and one click of the knob per increment - I am not sure how many clicks the knob does per turn. probably 16 or 32.

Don't forget though that as I pointed out earlier, some of use may use this inside our homes, and its not out of the question and that more than 10ms worth of delay may be required.

I think 20ms delay on the left or right channel would be heaps for any situation I can imagine.

The big question is, how much delay can we get without using up too much precious kernel memory - I assume you will have to store the delayed channel samples, there would be 88.2 bytes per ms of delay (for a single channel), so 20 ms would be 1700 bytes of buffer required.
This buffer may already be available in the Voladj hack Richard did - the PCM data stream certainly is. How far ahead does Richard's hack look for the Voladj stuff?

Hi there.

I had a quick look at this, and it should be pretty straightforward, actually. The audio driver in the kernel already has 8 * 4608 bytes of buffer, which the volume adjustment stuff piggybacks on. So if you didn't want to increase the memory footprint, you could reduce that to 7 * 4608 and use the remaining 4608 for the time shifting.

Shonky, if you're working from a volume adjustment kernel it would be easy to insert this functionality just after the voladj code does the scaling, perhaps you could call voladj_scale, and then voladj_shift directly after?

The UI is the hard bit. I'd be very tempted to simply add another parameter to the voladj_intinit and to the ioctl (probably a signed parameter in units of samples of delay), and then let somebody else come up with a decent UI.

Richard.

I knew it changed but I didn't think the speed of sound changed that much....

It will probably be in 0.2ms increments so most people are happy. That way I am currently doing things will allow a maximum of about 26ms (about 8-9 metres using my value for speed of sound). The distance given will be based on a fixed speed of sound probably - the delay in milliseconds value will be the accurate number.

Don't worry about the UI - I have that basically done already - just like temperature setting under Hijack. In fact it's just another Hijack menu.

I'm not using any of Richard's voladj stuff -it's basically all my code.

Speed of sound drop off - yeah its not going to be that noticeable anywhere that we'd be using our empegs in, and in any case the calculation to distance would be affected by change in speed not the actual delay - which would be whatever you entered.

Re: your own code, are you doing your delay before or after Voladj is doing its stuff to the PCM stream?

I wonder if you shouldn't do the delay after VolAdj has done its bit as if you delay one channel then Voladj won't see accurate view of the actual PCM stream as output by the mp3 decoder - and this may adversely affect the way voladj works.

Are you planning on getting Mark to put your hack into the std hijack kernel or will you release your hack seperately?

Its neat it will be in a hijack like option - easy to use, can't wait to try it out!

I'm actually doing it just before the voladj at the moment. Basically I am delaying anything that is coming from userspace into the kernel (i.e. from the player software)

Yes this probably will mess voladj up slightly but at the moment I am more going for proof of concept. I doubt 20ms is going to make much difference anyway.

I plan on getting it permanently included in Hijack - it basically has to be included in Hijack since it's a kernel mod otherwise people won't be able to download binaries from Mark's site. I would have to take Mark's patch each time he updates Hijack and then apply my patch and release my own binary -> yuck. It should and will be a hijack inclusion (assuming Mark let's me )

I agree with all has been said so far here. Your UI is basically what Tony proposed and what I would like too.
Yes, there's no need to delay both, that also seems to make little sense to me, it is the resulting difference in the two hypothetical delays that would matter, so there's no point in dalaying both.
As to the distance, I have no answer to what you ask. Your point is meaningful, I believe, unless the shape of the car interior could require delay values that are different from what you would simply measure by considering the distance between the driver and the speakers. But I am really just guessing, here...
And, sorry for not saying this before, a big big THANK YOU for your work!!

I haven't actually shown anything yet. So keep your hat on. I am trying to work out why it's not working. I'm sure my maths is right.

Before anyone offers help, I'd like to have a bit more of a go myself first. I like a challenge.

(edit) Getting closer. Anyone know how to quickly rebuild the kernel. It seems I have to do a make dep;make clean;make zImage everytime to ensure my changes stick. Takes much longer than just make zImage. And make zImage is definitely recompiling the file I have changed.

with the size of the car cabin being so small, you'd need very fine granularity in delay. If the unit is used at home, you'll need more range in the delay to take into account wider speaker placement, etc.

Calvin

In a car, although 1ms is 1/3 meter, the confines of the cabin is tight enough that we'd want sub-millisecond delays if possible. We want to be able to move things around by the millimeter. :-D

Calvin