I was just wondering if the data on the number of plays per track is stored anywhere you can access?

Or is it somwhere in dynamic partition?

It's part of the dynamic data partition.

logical place really.

Thanks Tony. Shame that stuff isn't documented.

Out of pure interest, what were you thinking of doing with the data? (maybe someone has already done it / is doing it).

Cheers, Sim

Your order number is 73
Order placed at Mon 3 Feb 2003 8:27 am

I've got 2 empegs and use rsync to update them. I was thinking it might be possible to somehow combine the play counter. Silly I know

Silly, maybe, but a complete reverse-engineering of that partition would be helpful for many reasons. There have been posts on this BBS by the Cambridge guys, suggesting that it's a fairly simple format and it shouldn't be all that hard to suss out.

Silly, maybe, but a complete reverse-engineering of that partition would be helpful for many reasons. There have been posts on this BBS by the Cambridge guys, suggesting that it's a fairly simple format and it shouldn't be all that hard to suss out.

Or they could just, *gasp* supply us with the format...

In the past, the justification for not doing so was that it wouldn't be worthwhile to do so since the format changes so much. With that in mind, reverse-engineering it and then writing something which depends on that format wouldn't be any more productive. Why can't they just give us a spec?

Then they can tell us they didn't tell us the format, and not feel guilty. I'm debating reverse engineering it, but if I do I'm not putting out anything until I can figure out how to tie it to a version or disable itself if it doesn't match.

I think we will probably get the spec when 2.0 is released.

In the past, the justification for not doing so was that it wouldn't be worthwhile to do so since the format changes so much.

OK. At this stage of the game it's pretty clear that the format isn't going to change for 2.0. We will change it post-2.0 as it includes two of the hard limits on the total number of songs usable on a car-player.

So you've got /dev/hda3. It's 16 megabytes long, or 32,768 sectors of 512 bytes. Sectors 4,096 to 32,767 inclusive contain the dynamic data, one sector per FID. So the data for, say, FID 0x4230 would be at sector 4,096 + 0x423.

Each sector contains a 2-byte length field, a 2-byte CRC field, and a data structure the prefix of which is described in lib/protocol/dyndata_format.h in an emptool source release. The CRC algorithm, which obviously only applies to the main data structure and not the length and CRC fields, is the "CRC::CRC16" algorithm from lib/protocol/crc.h in an emptool source release. None of this has changed substantially since before v1.00, although the structure length has increased and some fields were never filled in in older releases.

As you'll have spotted, this imposes a maximum of 28,672 files on the player (in fact, sixteen less than that, because the first fid is 0x100 not 0). So at some post-2.0 point, we'll rejig it to store several fids' data per sector, and whatever tools you're going to write with the information in this post will break.

Of course, tools which use lib/protocol to read and write dynamic data, like emptool does, will be insulated from this change.

(The other hard limit I mentioned is on the size of playlist that can be remembered over a shutdown: this information is stored in the first 512 sectors, in a way which changed between v1 and v2.)

Peter

COOOOOOOOOOL.

Someone please put this in the Developer Info section, posthaste.

bing!

Cool. So... No mention was made of how the tuner presets are stored. Is that something that can be gleaned from the emptool sources? Or is our assumption that they're stored on the dynamic data partition incorrect? While we're at it, aren't the EQ presets stored there, too?

Peter,

Thanks for the info. Now for the fun :-)

In reply to:

---

As you'll have spotted, this imposes a maximum of 28,672 files on the player (in fact, sixteen less than that, because the first fid is 0x100 not 0). So at some post-2.0 point, we'll rejig it to store several fids' data per sector, and whatever tools you're going to write with the information in this post will break.

---

I guess Paul is worried about this limit

If you have 2 drives, does it double the number of tracks or does it only use hda3?

If you have 2 drives, does it double the number of tracks or does it only use hda3?

I think only the first drive is used to store dynamic data.

lib/protocol/dyndata_format.h doesn't mention tuner or EQ stuff, both of which are supposedly on the dyndata partition.

OW!!! It is not nice to put hard limits on things!!!

I still have some headroom, though. At latest figuring, I have 20,301 unique files on the player, including playlists. (4f4d0&1)

Well, it's good to know one thing:

They can keep close tabs on how well their software works at the edge of the envelope, just by using Paul as their guide.

It will take a little while to get out there, though. It took me this long to get to that 20,000 mark. They might be on 3.0 by the time I get close to the edge.

bing!

I'd prefer to see a big bold warning at the top of that entry, saying that while the information applies to all software versions between 1.00 and 2.00 inclusive, it will become incorrect after that (I realise that the text says that further in as well).

Another thing to bear in mind, is that none of the player software was written in the expectation that third-parties would be writing to that partition, and so if anyone does feel like writing a tool that accesses it directly and not via lib/protocol, they should keep a clean backup of the whole partition somewhere ready to dd it back again if their changes make the player crash.

People wishing to back up their EQ and tuner settings should back up the 32 sectors starting at sector 2,048. The format of these blocks has changed several times since 1.0.

While we're on, the other entry on that riocar.org page is slightly misinformed: the swap partition can't be used for anything other than a swap partition, or synchronising will fail.

Peter

People wishing to back up their EQ and tuner settings should back up the 32 sectors starting at sector 2,048. The format of these blocks has changed several times since 1.0.

What about since 2.0 Beta 13? We've been talking about using the GPS to reprogram one of the banks of tuner presets. Any chance that format will change between 2.0b13 and Final?

Well if they put 8 fids in each sector and start using both drives partition 3 you would be ok for a while as the max would be 458,752

I would have thought that they could multiple (8) fids per seconds with just a couple of lines of change in the code.

I'm going ahead and updating the entry with the disclaimers and such. I hope that when changes are made in the post-2.0 releases, we'll be able to get an update on how the format has changed.

Note that anybody who wants a remote PC/workstation tool for reading (or re-writing) the dynamic data partition can start out by simply using Hijack kftpd/khttpd to GET/PUT /dev/hda3 (16MB file).

For software on the player that doesn't use the Empeg libs, just open "/dev/hda3"), and lseek() to the byte offset for the sector you want to read.

Cheers

Is the skipped_count updated?

I selected 1 album and put it on repeat. After it playing a few tracks I started again skipped all the tracks (including the 1 I was watching multiple times)

Here's the data :-

  

0000000 003c 32f7 0000 0000 0000 0007 75bb 3e41

0000020 472f 1df4 0000 0000 55a9 1555 ffff aa9a

0000040 a956 aaaa aaff fabf aaab fffe aa96 aaaa

0000060 fff9 bfff 0000 0000 306b 0000 03b6 0000

0000100 0000 0000 0000 0000 0000 0000 0000 0000

Is the skipped_count updated?

No.

lib/protocol/dyndata_format.h doesn't mention tuner or EQ stuff, both of which are supposedly on the dyndata partition.

Working on it...

Bleah, I need to go put the empeg in the dash so it has a tuner in order to do that part usefully. I'll look at the eq stuff now.

Sector 2048 has the eq stuff in it. I'm still playing, but it looks like the left channel starts at byte 229 and the right channel at byte 269, (each of the EQ bands using 4 bytes) and the left and right use up through bytes 268 and 308.

Makes sense since there are 10 bands, I haven't yet figured out the encoding or the significance of bytes 178 and 188 (which are 0 until the EQ is modified, and which probably represent some sort of bitmask of which bands are active (left and right respectively) or of bytes 5 and 6 (but it's going to be size or checksum)

Actually I think I mischaracterized that slightly. Stay tuned.

left channel starts at byte 229 and the right channel at byte 269, (each of the EQ bands using 4 bytes) and the left and right use up through bytes 268 and 308. These are probably the actual band definitions, more on that shortly.

Bytes 169-178 and 179-188 are literally the offset in db on each band, left and right channel. I see octal 377 at -1db, 376 at -2, and octal 1 at +1, octal 14 at +14.

Bytes 5 and 6 are going to be the crc, almost certainly. So let me figure out now what the band representation is.

The second set of EQ settings is in sector 2049. I guess the third set will be in sector 2050 and so on. Still going...

left channel starts at byte 229 and the right channel at byte 269, (each of the EQ bands using 4 bytes) and the left and right use up through bytes 268 and 308. These are probably the actual band definitions, more on that shortly.

Ok, so it looks like the 4 bytes decodes thus at each db setting in a band:
+12db to 94578288
+11db at 84286808
+5db at 42224896
+4db at 37630220
0db to 23736102
-1db to 26634296
-2db to 29886364
-3db to 33527318
-4db to 37630220

But the only indicator of + versus - db seems to be the simple index in bytes 169-178 and 179-188, and those are literal, so I don't understand what the point of these are. I don't know enough about equalizer application to know what this might be for. Comments anyone?

Derrick, remember that the eq is selectable between 2x10 or 4x5 channels.

Hmmm. Ok, I guess I need to figure out how to do that

I don't know whether that'd match with anything in kernel land, and whether taking a look at arch/arm/special/empeg_mixer.c (and friends) would help. If the player is storing the raw values as written to the kernel's IOCTLs then they may match up. If the player is storing 'user-friendly' values and converting on the fly, then probably not.

Actually the 2x10 versus 4x5 (when I figure out how to do it) probably isn't a big deal, just something indicating how the 20 channels are split.

I'm going to play with Q and the band setting and see what happens now.

Oh, I forgot to put it back in "car" mode. Sigh.

Ok, so it looks like the 4 bytes decodes thus at each db setting in a band:
0db to 23736102

Q is at .55 by default when the above happens. If I change it
If I change Q
.56 gives 24165598
.54 gives 23306606

Ok, so this is the result of the parametric function, I guess. Duh. I'm not very quick.

Byte 189 starts 20 sets of 2 bytes which are literal encoding of the band in hz. So for 50hz it's octal 62 in byte 189 and 0 in byte 190. For 18khz it's 120, 106. It tops out at 18khz. I guess what's left are:
-figure out how to toggle 2-4 channel mode, i need to reboot the player
-figure out the parametric equation.

Ok, so it looks like the 4 bytes decodes thus at each db setting in a band:
0db to 23736102

Q is at .55 by default when the above happens. If I change it
If I change Q
.56 gives 24165598
.54 gives 23306606

If I push Q to its extremes:
100.1 gives 4294537728
0.01 gives 429496

The resulting number varies linearly with Q, but my higher math is so far gone that I can't quantify this. I'll leave the equation to someone else, and move on to figuring out how 4x5 versus 2x10 is set. If I need to visit my car to get tuner info, that will have to wait until tomorrow.

Oh, I forgot to record Q for each of the db settings.
0: .55
1: .62
2: .70
3: .78
4: .88
5: .98
6: 1.1

And it's symmetric.

Byte 12 gets set to one when you're in 4 channel mode. Instead of having (the 2 byte) decibel offsets at byte 169 it appears to be at byte 29. Looks like fronts are at 29 and 39, the rears at 34 and 44. I guess this is since if 4 channel is enabled it's only on in car mode.

And it looks like the parameters which would start at byte 229 in the 2 channel case start at byte 89 in the 4 channel case. Front bands start at 89 and 129, rear bands at 109 and 149.

It looks like there are 16 sets of eq parameters, so 16 sectors 2048-2063.

All that should be left for the EQ is figuring out how to calculate the parameter given the Q and "db" settings for each band.

Good thing I managed to miss this message. Not that it was a big deal to figure this out.

Bleah, I need to go put the empeg in the dash so it has a tuner in order to do that part usefully. I'll look at the eq stuff now.

Nope, the fake_tuner stuff works fine. Also looking at this now.

Changing a preset A1 changes 2 bytes at byte 263, which I'm guessing are a CRC on either a bank or a station. The station name starts at byte 269 and runs to byte 276. I'll guess bytes 277-279 are the station but I can't prove that yet.
Two bytes at byte 283, and 2 at byte 477 also seem to be changing, sometimes, and I haven't figured out what they are. I think I will sleep and try to find some time tomorrow.

Haha I remember when I did this same reverse-engineering stuff on the empeg_flash block that stores the player state. Great work... Ain't it fun?

I haven't done anything like this in a while; I was probably overdue.

Hey Derrick (or Peter if you're still tuned into this thread.)

Where's the current running order (not playlist) stored? If I could programmatically get the FID of the next and previous songs, it'd help me a lot so I can cache the lyrics. Otherwise, it can take a good 3-5 seconds while the player and the lyrics scroller are both trying to read the MP3 fid at the same time. I'd love to be able to cache a few songs in advance.

No clue. Maybe when I finish poking at tuner...

equalizer sectors begin with 'EQUA'
it looks like tuner station records begin with 'OIDR' but are 256 bytes; record A1 appears to start at offset 256 into the first sector of tuner data. The station name is 8 bytes starting at byte 13 of those records. Guessing, bytes 7 and 8 are a CRC.

Byte 5 is 1 for FM, 2 for AM. Bytes 21-24 appear to be the station, but I don't know what the encoding is yet.

Actually, duh. For AM the 1380 appears to be encoded as 1380000. For FM 104.3 is 104300000. So it's just the frequency in hertz. Bytes 25 through 36 seem to change when I switch bands but I have no clue yet what it is.


.

Wow, I'd be interested in the current running order also. If Mark was nice enough to make this available in XML like the playlists, I could include the current running order in the web interface (default page, below the now playing).

Tom

I am not sure that the current running order is actually stored ANYWHERE.

If it's a premade playlist that's running, well.. the FID for the playlist is stored in the flash savearea, along with the FID of the currently playing track.

If it's a randomly convoluted playlist, then they probably just do the randomization on the fly, with known randomizer seed (maybe also stored in the flash savearea?). They could step forward/back through the "playlist" by just (re)generating the pseudorandom sequence on the fly.

???

Actually, I partially take that back.. the current playlist FID is NOT stored in the flash savearea.. and I don't see any "randomizer" or "playlist position" fields in the savearea, either.

So the playlist FID must be on disk (dynamic data partition) somewhere, but there's still no need to store the entire playlist there, as playlists are already in the database. For a random shuffle, they just need to keep track of the random seed, so it could be regenerated on the fly. I don't know if "order tweaks" survive power loss -- anybody?

??

Okay, nevermind, the current play order IS on the dynamic partition -- Peter even said so, I just missed it earlier.

The first 512 sectors (each sector is 512 bytes long) of /dev/hda3 is used for the current play order. Here's what I know thus far, using a short playlist:

There is something resembling the playlist, but incomplete, in the first sector. In particular, the early entries in this playlist appear to have been zeroed out, but otherwise it is in the same format as what I report below:

In the second sector, is the playlist, stored 8-bytes per entry. Within each entry, the first 4-bytes are the FID (little endian byte order), and the second 4-bytes appear to be the same for all FIDS, at least that's the way it looks for my simple 3-album playlist test case. Let's call this the "FID table".

I do not know what determines the size of the playlist, but immediately following it on disk is the play sequence, with 4-bytes per entry. Each entry consists of a 4-byte (liitte endian byte order) position index for the "FID table". When the playlist is not being shuffled, these are simply the values 0, 1,2,3,4,5,.. in sequence. But press "Shuffle" on the remote, and then look at it again (after the disk activity indicator goes on and then off again..), and you'll see the same position indexes, but now in a randomized order, such as: 1a,c,14,16,7,0,9,f,..

The same wierd position indexes can be seen in the first sector as well.. shuffled there as well.

One could presume that for a longer playlist, these two copies of the running order will each span multiple sectors, instead of being contained within the first and second sectors.

The way I'm poking at this is easy: I just pop up the Hijack "Vital Signs" screen, and watch the FID change as I use the FRONT PANEL BUTTONS to change tracks. This gives me the running order, and allows me to move forward/back at will, and see the effects of shuffling. Then I also do a hexdump of the first 512*512 bytes of hda3 (fetch it from the player using httpd, and then dump it in hex using tools on my Linux box).

Okay, somebody else take over now.

Cheers

Yep, tweaks are retained over a power cycle according to my quick test - Whole player shuffled, 'Hate Artist' on first 4 artists, 'Like Artist' * 3 to get first 4 tracks by the same artist. Track count and shuffle order both restored as expected.

I wonder whether this is the reason that selecting a new playlist sometimes takes a while - a small playlist seems to load immediately, whereas a long playlist 'hourglasses' (Disks already spun up in both cases, shuffle off). Since the whole database is already in RAM, and we only need to know what the first 4 tracks are for display purposes, database access doesn't explain it. In both cases we only need to start caching the first track before starting, so that doesn't explain it either. But if we needed to write the running order to the dynamic data partition then that would be dependant on playlist size.

One could presume that for a longer playlist, these two copies of the running order will each span multiple sectors, instead of being contained within the first and second sectors.

Yes. One could also notice that this area isn't really big enough at 512 sectors or 256K. If, in your playlists, you've got four references to each FID (say, once in an Artists playlist tree, once in Decades/Years, once in Genre, and an average of once more in ad-hoc playlists) then playing the whole player with down-down-down uses 24 bytes in this area for each track (8 for the "FID table", known as the "programme" in the player code, and four lots of 4 for the "play sequence", known to us as the "running order").

This means that if you've got more than 10,901 tracks on your player (which is not at all out of the question for a grzelakian, sorry gargantuan, player), and play all of them, then it won't be able to remember your playlist over a power-down. This is a genuine reported problem, and a much bigger spur to completely reorganising the dynamic partition than the 28,000-or-so limit on the per-FID dynamic area. But, as I said, we won't get round to this for 2.0final.

Incidentally, there are three more 512-sector-long playlist dump areas at offsets 512, 1024 and 1536: the three bookmarks.

Peter

Greetings!

You rang?

Still no word on the 80s yet...

This means that if you've got more than 10,901 tracks on your player (which is not at all out of the question for a grzelakian, sorry gargantuan, player)

I have an 80gb player that's not even full with more tracks than that.

And I always thought that playlists worked like a typical jukebox. When several people choose the same song, it will only be played once. Of course the jukebox won't tell you this and still keep your money.

So when I insert an album into my 'play everything' playlist, or use the 'same artist' thingy on the remote, it won't pull those songs out of the regular running order?

So when I insert an album into my 'play everything' playlist, or use the 'same artist' thingy on the remote, it won't pull those songs out of the regular running order?

No, I believe it leaves the rest of the playlist untouched.

But Peter was also refering to the fact that most people's playlists that reference the same song from different playlists, like a classical playlist and a mellow playlist would likely overlap to some extent.

So when I insert an album into my 'play everything' playlist, or use the 'same artist' thingy on the remote, it won't pull those songs out of the regular running order?

When you insert an album (whether from the search screen or the playlists menu), those tracks are added to the playlist, even if they were there already (even in shuffle mode). When you use the same artist thingy on the remote, those songs are swapped into position from wherever they are in the playlist -- it won't find songs by the same artist that aren't in the current playlist.

Peter

Peter, can you clue me in as to where I might look to get the current running order position, and the total number of tracks in the current running order? Like, when the Track:Info screen says:

[310/6521]

Are these values only in memory or are they in the flash savearea? Or somewhere else where one can read them?

Current position is in the flash savearea, stored as a 32-bit FID. Dunno about position within that FID.

-ml

Anyone else have any ideas?

Current position has to be stored somewhere. I was wondering if maybe the current Fid was used to index the running order, but I realised that would 'fail' on duplicates. However, I also remembered that duplicates are quirky anyway - they always get removed during shuffle, and re-inserted during unshuffle, so I checked...

If you have 1 track duplicated in a playlist, and the player is playing one of them at the point of shutdown, it will continue to play the correct one after power up.

The search continues...

And how about total length of the running order? That has to be stored somewhere too, unless the player counts them every time it boots up...

Edit: Length = number of songs, in this context.

Hmm...that depends. If the player keeps the whole running list in memory then it'd be trivial to either count each entry during load, or if being loaded as an array, to do a sizeof() and do the math after loading.

But if the player only loads as much of the running list as it needs then it would need to be stored.

I suspect that since the entire database is kept in memory then the whole running list is too.

Peter, can you clue me in as to where I might look to get the current running order position, and the total number of tracks in the current running order? Like, when the Track:Info screen says:

[310/6521]

Are these values only in memory or are they in the flash savearea? Or somewhere else where one can read them?

The first sector of each stored running-order (i.e. sector 0 for the current running order and sectors 512, 1024, and 1536 for the three bookmarks) contains a header structure that includes, among other things, the sizes of the programme and running order, the repeat mode, and the FID of the playlist used to form the current running order (or 0 if it's "custom" i.e. was made from search results or if inserts or appends were done to it).

The header also contains a running-order index and a timecode in centiseconds -- but these are only used for bookmarks; the running-order index and timecode for the current running order are stored to flash, not disk (so they can be written with the last dying milliamps if the player is yanked).

Mark's observation, that sector 0 contains a partial copy of the programme and/or running order, is due only to buffer reuse and is not significant.

The usual caveat applies: that all this will pass, like rain on the mountain, like a wind in the meadow, after 2.0final comes out.

Peter

This sounds like information that the The "Developer Info" gnomes should be collecting and re-posting...

The first sector of each stored running-order (i.e. sector 0 for the current running order and sectors 512, 1024, and 1536 for the three bookmarks) contains a header structure that includes, among other things, the sizes of the programme and running order, the repeat mode, and the FID of the playlist used to form the current running order (or 0 if it's "custom" i.e. was made from search results or if inserts or appends were done to it).

I don't suppose that header structure is in a .h file somewhere like the other dynamic data stuff is? (Just so you know, I really do plan on using this stuff, I'm not just asking out of idle curiosity.) I can possibly reverse-engineer portions of it, but if it was in emptool somewhere or you had it handy, that'd be of great help to what I'm doing.

The usual caveat applies: that all this will pass, like rain on the mountain, like a wind in the meadow, after 2.0final comes out.

That's fine, I'll be happy to bug you again for the new format when that happens. Semantic question, though... Does "after 2.0 final comes out" mean that 2.0 final will have a different format, or that the future releases beyond 2.0 will have a different format?

This sounds like information that the The "Developer Info" gnomes should be collecting and re-posting...

Well it sounds like the shelf life of this info might not be all that long... I'm going to hold off on posting this one until I can figure out some more details of what the bits and bytes all mean.

Does "after 2.0 final comes out" mean that 2.0 final will have a different format, or that the future releases beyond 2.0 will have a different format?

2.0 final will be the last release with this format. Releases beyond 2.0 will probably have a different format.

Does "after 2.0 final comes out" mean that 2.0 final will have a different format, or that the future releases beyond 2.0 will have a different format?

2.0final will have the same format, unless some sudden and desparate bug requires that we change it, which is very unlikely. The format isn't in an emptool source release, but it shouldn't be too hard to work out, at least for reading. There isn't even a CRC.

Peter

The format isn't in an emptool source release, but it shouldn't be too hard to work out, at least for reading. There isn't even a CRC.

Thanks guys, at least I know where to look now, I shouldn't have any problems deciphering it.

Go for it, Tony!

But we must all be careful not to be disappointed a year from now when we may be playing with v3-beta player software, and discover that (1) the format is entirely different, and (2) they (peter) cannot tell us anything about the new layout. I fully expect this to be the case, as the data layout on disk is one of the "tricks" they will have evolved, and will not want to share with any competitors.

So, by all means, we should take advantage of any knowledge of the current layout, and just plan on having to do it "the hard way" when it all gets pulled out from under us.

Cheers!

I fully expect this to be the case, as the data layout on disk is one of the "tricks" they will have evolved, and will not want to share with any competitors.

You really think that's the case? I'm not sure that on an EOL product, the layout of particular bits of information is all that much of a trade secret. I could be wrong, maybe they're sharing the same data structures with other living products... But I've found that, while the guys aren't spending their time advertising the formats or publishing them, they've been very helpful in casually pointing at a given area and saying "reverse engineer away, young man."

So, by all means, we should take advantage of any knowledge of the current layout, and just plan on having to do it "the hard way" when it all gets pulled out from under us.

Fellas, is Mark correct? Do you anticipate having to be more guarded about stuff like this in the v3 timeframe due to similarity to other products?

Fellas, is Mark correct? Do you anticipate having to be more guarded about stuff like this in the v3 timeframe due to similarity to other products?

The running order can be used to work out which songs you've listened to and which you haven't. Legally, that information is the copyright property of the record company.

No, actually I'm kidding. There are some specific things we feel nervous about helping people reverse-engineer, and I'm not going to be drawn on what they are, but hitherto this certainly hasn't been one of them.

Peter

No, actually I'm kidding. There are some specific things we feel nervous about helping people reverse-engineer, and I'm not going to be drawn on what they are, but hitherto this certainly hasn't been one of them.

Huzzah!

There are some specific things we feel nervous about helping people reverse-engineer

<cough>tuner settings</cough>

I'd guess it would be stuff about the serial number and other things. <paranoia>Or the secret mind control system that makes you want to go out and buy more empeg/SB stuff...</paranoia>

- Trevor

Go for it, Tony!

I got it!

I haven't worked out all the fields of the header in the first sector of hda3, but I found the fields I care about for my purposes. Here's what I've got (duplicating your previous information just for clarity)

0x0010:  playlist size (PS) 

0x0018:  running order size (ROS)

0x0200:  beginning of FIDs in the playlist, 8 bytes each

0x0200 + 8 * (PS):  beginning of the running order indexes, 4 bytes each

.
The ROS is only different than the PS if you've shuffled (due to duplicate removal.)

So with the above information, given an index into the current running order, I can find the FID number associated with that index. That's not very interesting for the currently playing FID, because we can get that from many areas, including the flash savearea and /proc/empeg_notify. BUT.. Cobbling this information together allows me to get the NEXT fid that will play in the current running order. If I'm at index N of the running order, I just need to go to index N+1, follow that as an index into the FIDs area at 0x200, and there we have it. I wrote a tiny C program to convert a running order index into a FID and it is working flawlessly. Righteous!

Now all I need is a way to get where we're at within the current running order from the userland... It's in the flash savearea, but there's no ioctl() for that. If there was, well, my master plan is going to start coming together very nicely.

Sweet, now I can finally go back to working on my school projects...

Now all I need is a way to get where we're at within the current running order from the userland... It's in the flash savearea, but there's no ioctl() for that. If there was, well, my master plan is going to start coming together very nicely.

I guess if Mark doesn't do something I'll write a patch.

The savearea is readable from /dev/empeg_state. The stock kernel doesn't allow multiple readers in there at once though, so Hijack v314 will be out shortly with that capability added.

Cheers

Woohoo!

Ok, so I'll find something more useful to do.

I sent a patch to Jan for gpsapp which implements real time display of NMEA strings, but I'm not overly happy with it. He hasn't commented yet so either he's busy or he isn't either

I was going to try something with raster underlays for the gpsapp route screen, and worked out a way to color-reduce a geotiff using the USGS colormap standard to something which would display what I considered "interesting" information and punt the rest, and then actually thought to crop a 128x32 section and noticed it just wasn't large enough until I went to 4x zoom out.

Maybe I should play with trying to figure out saved tuner settings some more.

Yeah, I've been kind of busy this week, so I haven't had a chance to look at the patch. btw. Why is is useful to see realtime NMEA strings? If it is to check whether the gps -> empeg connection is working, perhaps having something simple like a virtual flashing led that toggles whenever we've received serial input, and possibly flashes with a brighter color when we've actually been able to interpret this input. That would be more generic as it is applicable to the non-NMEA protocols as well.

Why is is useful to see realtime NMEA strings?

Didn't someone ask for it for time ago? I have no idea why, I just had this idea that someone wanted it. If I'm nuts, it's probably not worth doing that way. I can do a "flashing led" easily enough.

Didn't someone ask for it for time ago?

I think that was before we had the satellite info screen which gives us some feedback before the gps obtains a good lock and starts sending position updates.

My guess is that early debugging (i.e. did I cross those rx/tx wires) could use some additional feedback, but that should probably stay inobtrusive enough that it won't bother a user once everything is up and running. Which is why a small flashing circle in the 'blind spot' in the upper left corner could be useful.

My guess is that early debugging (i.e. did I cross those rx/tx wires) could use some additional feedback

I think "waiting for data from GPS receiver" is sufficient for that one.

Ok, so it looks like the 4 bytes decodes thus at each db setting in a band:
0db to 23736102

Q is at .55 by default when the above happens. If I change it
If I change Q
.56 gives 24165598
.54 gives 23306606

If I push Q to its extremes:
100.1 gives 4294537728
0.01 gives 429496

A quick resurrection.

It looks like Q = 100*value/ 2^32
I'm guessing that the marginal inaccuracies that we see in the above figures is due to display rounding in the player software. Certainly a 'strings' of the player binary reveals that the display is a printf formatted variable using a precision code, and not a preformatted string.
Using the above formula;
.56 gives 24165598 gives 0.5626
.54 gives 23306606 gives 0.5426
100.1 gives 4294537728 gives 99.98 <== oddity.
0.01 gives 429496 gives 0.00999

In reply to:

---

100.1 gives 4294537728 gives 99.98 <== oddity.

---

Perhaps the fraction is Q = 100.1*value/ 2^32 (since 100.1 is the largest value)?

It fits the values perfectly if you use 100.11 and do rounding to 2 d.p. Bit of a weird number to multiply by so there might be something we're missing still on this calculation.
Does anybody have any more values to check against?

- Trevor

Well, I can't understand why it would use 100.11...My suspicions are that the equation is Q=100.X / 2^32, and that an error is being introduced in the display. Possibly the user input being adjusted by the player is converted to DSP coefficients, and then reverse-calculated for display purposes. Given the lack of native floating point support within the ARM, the code probably uses fixed point math, which could introduce small errors, especially with a double conversion. Purely speculation...

I think that we can live with the accuracy of Q=100.X / 2^32 for anything we might want to do.