Flat file structure 30+ files

Designing hardware and software for systems that use the VS1010 MP3 Audio DSP Microcontroller.
Post Reply
stanton
User
Posts: 5
Joined: Sat 2020-01-04 12:54

Flat file structure 30+ files

Post by stanton »

Hello

I would like to have more than 30 mp3 files in the root (or single sub directory) of a USB key attached to a VS1010 and be able to play them in sequence and navigate sequentially through them (forwards and backwards) with a press of a button. These files will all have 8.3 name formats. Each file represents a chapter in a book and the user needs to move forwards and backwards through the chapters. There is no screen for navigation of a file hierarchy.

I see the vs1010 handbook suggests a limit of 30 files is imposed by the OS (although perhaps I have misunderstood?) Why is this and is this extensible?

What is the best way to handle a simple sequential navigation through >30 (and most likely < 100) files?

Thanks in advance
User avatar
Panu
VSDSP Expert
Posts: 2816
Joined: Tue 2010-06-22 13:43

Re: Flat file structure 30+ files

Post by Panu »

Code: Select all

u_int32 sortlist[32]; u_int16 indeks[32];
ioresult vo_rom_openfile_sorted(register __i0 VO_FILE *f, const char *filename, const char *mode) {
	static u_int32 currentSort; u_int16 newSort; int i; int n;
	if (mode[2] == '#' && ((newSort = Crc32String(filename)) != currentSort)) {
		for (i=0; i<sizeof(indeks); i++) indeks[i]=i;
		currentSort = newSort; sortListPtr = sortlist; sortListEnd = &sortlist[30];
		i = f->op->Open(f, &filename[2], "r##99"); //perform the sort
		n = sortListPtr - sortlist;
		if (n<30) { sortListPtr = sortlist;	qsort(indeks,n,1,(void*)FNCompare); }
	} 		
	sortListPtr = 0;
	return f->op->Open(f, &filename[2], mode);
};
Hi!

The code above from VS1010 ROM allocates RAM for an array of 32 sort indexes and four ASCII characters per file. So relying on the ROM only, you get up to 32 entries (., .. and 30 file/directory entries) sorted automatically by the first four characters of their 8.3 file name. Larger directories will not be sorted at all.

This is enough for some of our customers' projects such as tour guides, where quick finding of files is ensured by making a tree-like directory structure based on their first letters, or by title, chapter (titles in first directory level, chapters in second directory level etc).

For generic MP3 collections, I've written an indexer that in the first phase uses all RAM of VS1010 to build an index. It might be helpful. It can sort directories with combined file name length of 9000 characters and it was able to index an SD card with 20 000 MP3 sonds in just 6 seconds of real time. In case you're wondering, that kind of index does not fit into VS1010 RAM as such. Instead, it builds a list of "shortcuts" in memory that dramatically reduces search time during playing, for instance if you want to open song number 12345, it might have in memory a shortcut that remembers that that song number is located in a directory whose first song is number 12330 so it just needs to search from 12330 to 12345 step by step, which it does considerably faster than searching from 0 to 12345 incrementally.

Any ideas based on this?

-Panu
Post Reply