#129576 - Noda - Wed May 23, 2007 9:36 pm
*EDIT: Nevermind, the problem was cause for an unknow reason by the libfat, now it's working correctly. I found the performance quite low compared to what's announced, is the performance difference between GCC & ADS so high?
| simonjhall wrote: |
| Quote: | | Great news!! Which MP3 player did you use? is it possible to make the source of this player available, I this I could interest a lot of people (including me!) as it's a nice way to add music into games :) |
Check out https://datatype.helixcommunity.org/mp3dec.html, it's pretty easy to get going. To compile you almost just do 'arm-eabi-gcc *.c -c" on the directory of about ten files. I then modified the demo program by about five lines to send the sound to the hardware, rather than disk. Ea-sy.
|
hi,
today I tried to build a test which use this player, but for now I'm stuck with a serious problem :/
to compile, I just added a #define ARM so the lib knows the architecture, and modifier the makefile to allow ASM code (not thumb):
| Code: |
#ARCH := -mthumb -mthumb-interwork
ARCH :=
|
and added all the necessary source dirs:
| Code: |
SOURCES := source data source/mp3 source/mp3/real source/mp3/real/arm
|
and juts modified the example to not output result to a frame but to a memory buffer, then play this memory buffer.
All compiles fines (just a few warning about using uninitiliazed values dues to inline ASM code), but crashes on line:
| Code: |
/* find start of next MP3 frame - assume EOF if no sync found */
offset = MP3FindSyncWord(readPtr, bytesLeft);
|
any idea?
or maybe you could send me your example/test config if you still have it?
thanks
#129589 - simonjhall - Wed May 23, 2007 11:59 pm
I was just about to give you my makefile :-)
Anyway, yeah I found the performance to be a bit shit. Bear in mind however that I'm running the decoder on the second processor which is slower and has no data cache, plus streams the data via the primary processor :-S
When I'm just playing music on the main processor the speed is much better, but it's still nowhere near the quoted speeds. They do say however that the the numbers are simulated and it's running on a machine with zero-wait state RAM... Is that supposed to mean that when a load is issued, the data is in the register the next clock?
EDIT: woo, we're onto page fifty of the thread!
_________________
Big thanks to everyone who donated for Quake2
#129750 - Noda - Sat May 26, 2007 1:15 am
Ouch!
I apologive for the ENORMOUS mistake I said here O_o
I previoulsy tested the decoder on no$gba, I thought it was accurate on timings...
With a 44k 80kbs stereo mp3 on the arm9, no$gba gave me a 81% realtime performance, quite shitty so...
Just tested the same on my DS lite as I was really wondering about this huge difference of performance between what was annouced and my tests, and guess, what? on DS lite, performance was 570% realtime!! :) a lot better so...
I'm now going to bench it with a good 44k 320kbps stereo mp3, I'll give the results later...
Then I'm quite now confident that the ARM7 could easily handle a 128kbps stereo file, I can't wait to test it :p
EDIT: The results!!! mp3 44k 320kbs stereo on arm9... 289% realtime! so the result are quite in line with what was annouced:
- annouced: mp3 48k 320kbs stereo -> 24Mhz arm9
- tested: mp3 44k 320kbs joint stereo -> arm9, 66/(2.89) = 22Mhz
So I must admit that this decoder have a VERY good performance :)
I'll announce the test result on the arm7 as soon as the binary is ready to test...
#129757 - tepples - Sat May 26, 2007 4:03 am
| Noda wrote: |
With a 44k 80kbs stereo mp3 [...] on DS lite, performance was 570% realtime!! :) a lot better so...
I'm now going to bench it with a good 44k 320kbps stereo mp3, I'll give the results later...
Then I'm quite now confident that the ARM7 could easily handle a 128kbps stereo file, I can't wait to test it :p |
In practice, 32k 80kbps should be enough given the DS's 10-bit 32768 Hz DAC.
For comparison, GSM Player on GBA gives nearly 200% realtime, which allows most of the frame time in Luminesweeper to be used for game and graphics logic.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#129798 - Noda - Sun May 27, 2007 1:31 pm
Tepples> yes, you are right, but I used high birate just for performance testing ;)
And finally the benchmark results with the arm7:
- mp3 44k 80kbps joint stereo: 142% realtime (23Mhz usage)
- mp3 44k 128kbps joint stereo: 113% realtime (28Mhz usage)
- mp3 22k 64kbps joint stereo: 227% realtime (14Mhz usage)
So far, the results are very good :)
No I just need to implement a proper streaming system and even a child would be able to add music to homebrews ^^
#129821 - tepples - Sun May 27, 2007 5:19 pm
| Noda wrote: |
| No I just need to implement a proper streaming system and even a child would be able to add music to homebrews ^^ |
But who would compose it? And if you have the source code for a music, can't you just convert it down to S3M?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#129822 - Noda - Sun May 27, 2007 5:33 pm
Obviously, there's no "source code" for music... and you can't just convert a song to a mod format, you have to compose it for this format.
| Quote: |
| But who would compose it? |
The same for the mods, no?
Composing a music in a mod format is very restrictive and specific, wheras with mp3 format you can just compose music with the hardware/software you want, and do a *lot* more compared to what you can do with a mod...
And I'm sure of what I says, as I'm a semi-pro music producer and used to compose mods in the nineties ;)
#129831 - tepples - Sun May 27, 2007 8:13 pm
| Noda wrote: |
| Obviously, there's no "source code" for music |
O RLY?
| Quote: |
| Quote: | | But who would compose it? |
The same for the mods, no? |
Exactly. You still have to commission a composition no matter what playback technology you are using. If you're using MP3, you also have to distribute larger files, which can eat into your bandwidth bill especially if you and your users are on different continents *cough*Australia 3 GB/mo caps*cough*.
And does your CPU use figure include the digital signal processing needed for speeding up the music's tempo (without changing its key) when time is running low? And does the API allow for decoding multiple files at once and mixing them if you want effects similar to the music of of Super Mario 64's water and cave levels, which turn on groups of instruments when the player is in a given region?
You say you're a semi-professional in music production. What do you recommend that people do to avoid copyright infringement through subconscious copying?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#129861 - Noda - Mon May 28, 2007 12:40 pm
| tepples wrote: |
| Noda wrote: | | Obviously, there's no "source code" for music |
O RLY?
|
Sorry, but a musical score can't be compared to a music "source code":
with a given source code you can build the exact copy of the binary -> not with a score...
A score is more like an "algorithm" if you still want a comparison, as it only give the general idea, but the implementation can be each time different.
| Quote: |
| Quote: | | Quote: | | But who would compose it? |
The same for the mods, no? |
Exactly. You still have to commission a composition no matter what playback technology you are using. If you're using MP3, you also have to distribute larger files, which can eat into your bandwidth bill especially if you and your users are on different continents *cough*Australia 3 GB/mo caps*cough*.
And does your CPU use figure include the digital signal processing needed for speeding up the music's tempo (without changing its key) when time is running low? And does the API allow for decoding multiple files at once and mixing them if you want effects similar to the music of of Super Mario 64's water and cave levels, which turn on groups of instruments when the player is in a given region?
You say you're a semi-professional in music production. What do you recommend that people do to avoid copyright infringement through subconscious copying? |
There's no more copyright problems with mp3 than with mods...
Why are you talking about music piracy here? you think that homebrew coders are not capable of composing music by themselves? I'm working on mp3 support because I want to include in my games some musics I've done that can't be made with mods...
And sorry, but for me you seems to be complety closed on your little "hardcore" homebrew coder world, as obviously mp3 music won't be used in the same way as mods... Do you think Tony Hawks' sountrack have been remade with mods, re syncing voices again, etc? obviously no as it would have taken more room than a simple flat record...
PS: Simon, sorry for going out of the quake subject here, I think this discussion should be splitted in a new thread....
#129863 - simonjhall - Mon May 28, 2007 1:38 pm
Haha, no problem. This thread is huge any way :-)
Regarding mp3 playback, when you get the streaming stuff working out properly, reckon you could tell me how you do it? At the moment I've got clicking... (but I'm too lazy to sort it out)
_________________
Big thanks to everyone who donated for Quake2
#129864 - Noda - Mon May 28, 2007 1:58 pm
I'll send you the source as soon as the streaming part is ready and working fine. I'm also currently working on size optimisation for the mp3 codec, I think you could also be interested with that part ;-)
#129869 - kusma - Mon May 28, 2007 3:07 pm
Noda: Great work on the MP3-playback. I'd love to see the low-rate 14Mhz-version being ported to GBA :)
#129872 - tepples - Mon May 28, 2007 3:24 pm
| Noda wrote: |
There's no more copyright problems with mp3 than with mods...
Why are you talking about music piracy here? you think that homebrew coders are not capable of composing music by themselves? |
For the use case of music composed by a member of the homebrew scene: What I'm saying is that I want to know how not to make the same mistake that George Harrison made (Bright Tunes Music v. Harrisongs Music, regarding the song "My Sweet Lord"). There is little or no difference between ogg/mp3/mp2/gsm and it/xm/s3m/mod in this respect.
For the use case of other music: The streaming formats increase temptation for a homebrewer to introduce obviously pirated music, as the homebrewer can just use the commercial recording instead of making a (still unauthorized) cover version.
But as for a GBA version, that might not necessarily work so well, as unlike the ARM9 in the DS, the ARM7 in the GBA has no cache.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#129884 - Noda - Mon May 28, 2007 5:42 pm
Yes, you are right about those kind of problems, but for me it's not a big issue as it's the same kind of problem as with the gfx : lots of homebrews make use of copyrighted artwork... But because homebrews are amateur work given for free, most of the time copyright owners don't mind this, and no problems occurs. (I think I can feel lucky with my Warcraft game, as Blizzard haven't contacted me yet ^^)
But sure the legal issue is still there.
And for the GBA part, I think it's feasible, just look at my performance tests on the arm7: mp3 22k 64kbps joint stereo use only 14Mhz, and the gba ARM7 is the same as the one of the DS, but clocked at 16,78Mhz so it can be feasible. For now I didn't make anything special, I just downloaded the source code, and modified some line of the example project. You can try it by yourself easily :-)
#129886 - kusma - Mon May 28, 2007 6:08 pm
While it's true that the GBA doesn't have a cache, I think a replay-rate of 18khz might be enough, and the saved cycles on that could about weigh up for the lack of the data and instruction cache. Maybe. ;)
#129896 - Noda - Mon May 28, 2007 9:33 pm
The GBA doesn't have any cache, but neither do the ARM7 of the DS, so I think the 22k 64kb stereo mp3 could also be decoded on the gba ;)
#129903 - kusma - Mon May 28, 2007 10:43 pm
Oh, wait... it doesn't? That pretty much kills off some coding idea I had :(
#129904 - Noda - Mon May 28, 2007 11:02 pm
The arm7 lacks cache, but have quite a good performance even though ^^
#129905 - simonjhall - Mon May 28, 2007 11:30 pm
| kusma wrote: |
| Oh, wait... it doesn't? That pretty much kills off some coding idea I had :( |
Uh-oh, this ain't what I think it is, is it?
_________________
Big thanks to everyone who donated for Quake2
#129911 - tepples - Tue May 29, 2007 12:26 am
Not only does the GBA ARM7 lack a cache, but it also has a smaller IWRAM.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#129913 - kusma - Tue May 29, 2007 12:45 am
| simonjhall wrote: |
| kusma wrote: | | Oh, wait... it doesn't? That pretty much kills off some coding idea I had :( |
Uh-oh, this ain't what I think it is, is it? |
It sure is! :(
#129914 - kusma - Tue May 29, 2007 12:58 am
| tepples wrote: |
| Not only does the GBA ARM7 lack a cache, but it also has a smaller IWRAM. |
The 14MHz profiling was done against the DS ARM7 which (at least according to Noda here) isn't cached either. So the big difference is really the amount of IWRAM. And I would assume that it should be possible to solve. I bet only parts of the decoder would need to run from there.
#145911 - chishm - Sun Nov 25, 2007 3:12 pm
I'm looking to add ARM7 mp3 support to one of my projects and I was wondering how far you got with this. Do you have any code, or even a complete ARM7 core to drop into my project?
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com
#145913 - Lazy1 - Sun Nov 25, 2007 4:12 pm
I did a streaming version but the IPC is a complete joke:
http://forum.gbadev.org/viewtopic.php?t=14371
It does work though.
#145925 - Noda - Sun Nov 25, 2007 7:24 pm
I'm actually in the work for a complete sound library, which will supports proper mp3 streaming from the arm9 and decoding on the arm7, and a surround sound mixer with priority support ;)
#145947 - chishm - Mon Nov 26, 2007 3:41 am
Noda:
Ah, so it's not ready yet. That's ok, I'll try to port helix myself.
Lazy1:
Yeah, I tried that and it doesn't work with DKA r20. I only hear silence.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com
#145948 - Noda - Mon Nov 26, 2007 4:59 am
chism:
I'll integrate this lib in my school project which is due in 2 weeks, so it will be ready really soon (it's somewhat 65% done for now). ;)
#145949 - Lick - Mon Nov 26, 2007 5:14 am
| chishm wrote: |
| I only hear silence. |
That sentence made me think for hours.
_________________
http://licklick.wordpress.com
#145950 - Lazy1 - Mon Nov 26, 2007 6:40 am
I forgot to mention it only does mono, that's probably why.
Since the music for wolf3d was going to be mono anyway I never bothered with stereo.
#145952 - chishm - Mon Nov 26, 2007 8:38 am
Noda:
I don't think I can wait that long. I need instant gratification ;-)
Lick:
There is a whole song written about the sound of silence.
Lazy1:
Stereo files should give a weird half-rate, clicky version of the mono file. The Helix decoder interleaves the results, so that is what would be expected.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com
#145959 - Lazy1 - Mon Nov 26, 2007 3:12 pm
What I meant was the MP3 is only decoded if it has 1 channel, else it's ignored.
I think I should re-write to support stereo though.
#146033 - Noda - Tue Nov 27, 2007 10:32 pm
chism:
if you still don't have done it yet, my library is somewhat ready for beta testing (I just need to clean up some code), and everything seems to be working as expected: mp3 play on arm7 (with & without streaming) & sound engine which is based on priority to skip/stop sound when no free channels are available, and has surround and (a sort of) reverb support ;)
As I don't plan to make it publicly available until the end of my project, please PM if you want to beta-test it for me ;)
#146036 - Lazy1 - Tue Nov 27, 2007 10:35 pm
Could I get in on that beta test?
As long as the arm9 code is free of restrictive licenses I could use it to replace my hacky mp3 code.
ARM7 Licenses don't matter but it should be able to be built separately.
#146037 - Noda - Tue Nov 27, 2007 10:43 pm
No problem, as long as you also test a little bit the sound functions and not only the mp3 ones ;)
And as I did with the EFSlib, this lib will come under the "do what you want with it" license (better known as "do whatever you want with it") ;)
Just remember that the helix decoder part is under license though..
I'll PM you when the beta package is ready.
EDIT: humm I had a discussion with my shcool tutor, it would be better if I don't release it until my school presentation & paper are done, so I guess you'll have to wait 2 weeks, sorry...
[Minor correction -- MOD]
Re-correction: public domain is dependant of countries, for example in france you need to wait 70 years after the death of the copyright owner to have a work in the public domain, so I prefer to say that I use no license.
Last edited by Noda on Thu Nov 29, 2007 7:09 am; edited 1 time in total
#146054 - chishm - Wed Nov 28, 2007 2:23 am
Thanks for the offer, but I have an MP3 decoder going now, with help from LiraNuna, Strager and DarkEz. It does mono MP3s up to at least 128Kb/s, but I can't seem to get stereo to work. Either the ARM7 doesn't have enough power to decode stereo, or I'm not de-interleaving it correctly.
Also, the Helix license isn't completely compatible with the GPL. Luckily all GPL code I use is on the ARM9 and the Helix decoder is running on the ARM7.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com
#146058 - Noda - Wed Nov 28, 2007 3:07 am
No problem with stereo here, I used an ASM desinterleaver which works just fine ;)
And from my tests, I went up to 44Kh/stereo/96kbps on the arm7 with streaming from fat without problems, but with stereo/128kbps file it seems that reading from fat is too slow on my DSX to work with my tight timing system (I could go with a larger read buffer [currently 8Ko] but I don't see the point of using such high bitrate, 32Khz/stereo/80kbps is already better than enough considering the DS DAC..)
#146059 - chishm - Wed Nov 28, 2007 3:32 am
I might have to look at your code when it's done. Stereo is always nice. My buffering system should handle it easily enough.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com
#146061 - Lick - Wed Nov 28, 2007 4:11 am
Chishm, are you going to publish your implementation?
_________________
http://licklick.wordpress.com
#146064 - chishm - Wed Nov 28, 2007 4:55 am
I will when I'm finished, provided all co-contributors agree. As I said before, I've had quite a bit of help getting this to work, so I want to make sure everyone is credited properly.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com
#146069 - Lazy1 - Wed Nov 28, 2007 10:52 am
I couldn't get stereo working either but I never really needed it anyways, the limit I found was 128kbps mono at 32000Hz.
#146077 - FireSlash - Wed Nov 28, 2007 5:43 pm
Lazy1, does your implementation work with the latest dkp? I know the old versions do not.
_________________
FireSlash.net
#146079 - Lazy1 - Wed Nov 28, 2007 5:59 pm
I developed it with r21, however like I mentioned earlier the IPC method is a joke.
The decode process works perfectly though aside from ignoring stereo MP3s.