This is the bug/patch tracker for Rockbox. Click here for more information.
Quick links: Bugs · Patches · Rockbox frontpage
FS#12176 - New Chiptune codec pack based on Game_Music_Emu library ;)
|
DetailsHi, this is a codec pack containing all codecs based on blargg's
Game_Music_Emu library. I have ported all code to C to work in ROCKbox, and i have replaced the MAME versions of some emulators with others compatible with the GPL license. It was a lot of work but i did it because i really love chiptune music and having the possibility to listen to a lot of classic video game system's music in a small player is really great ;). Original Game_Music_Emu library here: http://slack.net/~ant/libs/audio.html Tested on: Sansa Fuze v2 Created from revision: 30084 The following formats are contained in the pack: - AY (ZX Spectrum, Amstrad CPC) - GBS (Nintendo Game Boy) - HES (NEC TurboGrafx-16, PC Engine) - KSS (MSX Home Computer, other z80 systems) - NSF, NSFE (Nintendo NES, Famicom) - SGC (Sega Master System, Game Gear, Coleco Vision) - VGM, VGZ (Sega Master System, Mark III, Sega Genesis, Mega Driver, BBC Micro) Additional features: - 44100 Khz, stereo playback. - Support all sound chips in NSF/NSFE formats. - Support MSX-AUDIO and MSX-MUSIC in KSS format . - Support ADPCM samples in HES format. - Support for extended m3u playlists created specially for some chiptune formats. Known issuses: - Some (or all) codecs might not work in some targets, specially if they have an small iram size, or if the codec is too cpu intensive, like VGM and KSS. - Subsong change is not working properly, specially when it happens automatically. - Most vgz tracks will be truncated due to the small amount of free memory available to uncompress them. - Some SCC+ soundtracks might not work correctly. ** There might be several bugs and issues to be found yet, so please feel free to report them here or to my mail address. Special thanks to: - Shay Green (blargg) the original author of the great Game_Music_Emu library. - Chris Moeller (kode54) who made some nice improvements to the library. - Mitsutaka Okazaki, author of the YM2413 emulator. - The OpenMSX team for the YM8950 emulator. - Stéphane Dallongeville for the YM2612 emulator. - Joshua Chang, Haiku Konaru and everyone else who has helped me to test the codecs. 
gme_codecs_v1.0.zip
(265 KiB)
|
This task depends upon
Do you replace the current nsf codec with one based on this library?
What is this bios in sgc.c? Where do you get it from?
Some questions additionally to kugel's:
- The codecs are all played via a single library. Is IRAM shared for the whole library?
- Can you provide a sample for each format? We need such for future performance and regression tests.
- Can you add a patch to enhance the manual especially in the codec and metadata section?
- Does this patch incorporate or replace your other patches
FS#12021,FS#11999, FS#11978,FS#11945andFS#11906?also, a little problem i've forgotten to mention longlong ago, the nes_fds_apu's regs declaration was conflict with some targets‘s define(gigabeat fx?), i've modified the files, see attachment
Another question: Some codec(s) in the patch use malloc. Is that malloc better or can it be replaced with with the tlsf_malloc() we have in the codeclib?
> Do you replace the current nsf codec with one based on this library?
Yes, i believe the nsf codec based on Game_Music_Emu library has superior quality in both emulation and sound. Someone mentioned the
current nsf codec had better playback controls though.
> The codecs are all played via a single library. Is IRAM shared for the whole library?
All codecs compile independently using only the files they need. Some people suggested it would be a better idea to put all files in the same folder.
> Can you provide a sample for each format? We need such for future performance and regression tests?
Well i guess i could get some help here, maybe search for tunes that are cpu intensive.
> Can you add a patch to enhance the manual especially in the codec and metadata section?
I could get some help here too ;)
> Does this patch incorporate or replace your other patches
FS#12021,FS#11999, FS#11978,FS#11945andFS#11906?Yes, it incorporates and also replaces all patches, except for FS#11978, the Atari sc68 patch.
FS#12113which did an IRAM optimization to the current nsf implementation -- we should be abel to keep tor reinvent this as the speed up was massive (an example file is attached in this task as well).> Well i guess i could get some help here, maybe search for tunes that are cpu intensive.
Searching for files that are CPU intensive is a good idea, but not mandatory for a first step. Do have a test file for each codec available -- independent of CPU needs?
> I could get some help here too ;)
I have attached an example for the manual enhancement using "GBS Nintendo Game Boy". You will need to change 3 parts of the manual section for each codec:
1) Add it to the codec tables. All of your codecs from this patch will all be "Others" (not lossy, not lossless). Add any comment, if the codec has some special limitations (e.g. seek subtracks instead of seconds)
2) Does the codec use some standardized metadata tag (ID3, ASF, ...) or does it use its own format (like GBS does from what I saw from your patch) or does it not support metadat at all?
3) If the codec uses its own metadata format: what kind of data is supported? I filled the table for GBS based on your patch's metadata source code.
Maybe a couple of notes should be added, for example, the possibility to use an extended m3u to get some extra metadata info
and subtrack remap. But not sure where to put those.
I also included a test file from each format, with their respective credits in the README file.
Few more questions:
- vgz is just zipped vgm and handled by the same metadata parser and decoder? If so, I would just make a single codec entry to the manual, add both suffixes and add a note regarding the zipped version.
- Is the same metadata set supported for vgm and vgz? If so, this should be added to the manual as well.
Yeah vgz are just zipped vgm (using gzip algorithm), but the only way to get the metadata is uncompressing them.
> Is the same metadata set supported for vgm and vgz?
For now the metadata parser only handles vgm files. I guess it would be too slow to uncompress each vgz to get the
metadata.
Edit: I am not sure if it is a good idea to have all of those codecs in a single directory. Is it possible to move the different codecs to seperate paths? Common used parts could be placed in libgme. This is similar to what we do with libm4a or libasf.
IRAM is still not used with the attached updated patch, but the patch allows to enable IRAM now with some minor code changes. Please see apps/codecs/libgme/blargg_common.h (line 23-35) for details.
Yeah sorry about that, i tryied to use it based on the old nsf and spc codecs (before r29886) but didn't have any
way to benchmark or even test it.
The problem is that only a two c files are common between all codecs: blip_buffer and multi_buffer. The other common files are headers: blargg_xxxx.h, m3u_playlist.h, etc. Would there be any advantage doing it?.
try to add NDEBUG 1 in blargg_common.h
> Yeah sorry about that,
No need to say sorry. Let's just keep working on this stuff ;)
Regarding the path-structure: It is just not my personal taste to have it all in one directory. But if a) this is the way GME is structured and b) there is only few common code just leave it like it is. Will make it easier to update GME.
Also to push fixes upstream (although I'm aware we historically don't do this).
I am trying to get one of the players that have large IRAM for testing, but i can't find one here in my country and Amazon doesn't
ship electronics to Mexico. I know about the ipod nano, gogear, sansa c250. Could someone tell me what other players benefit from using IRAM?.
gama, is there any CPU intensive codec contained in this patch? I do not insist on fully optimizing this stuff before bringing it to svn. We can do this later -- especially as I do not expect too high CPU requirements for most of these codecs.
Didn't know about that ;).
The most cpu intensive CODEC is VGM, we can try including some profiling code first to find the most cpu intensive parts, i think we can use the spc_profiler as basis. I'm pretty sure that since the original library was wrote in c++, there must be a lot of room for optimization. For instance, someone may write an ASM resampler ;).
Would it be possible to provide a patch against upstream "libgme"? To see what's effectively your code and what's imported.
Usually this helps a lot more then IRAM. Its mostly older CPUs that benefit a lot from IRAM. On newer devices the difference is often fairly small due to better caches.
>For instance, someone may write an ASM resampler ;).
Are you actually resampling? Our playback engine should be able to take most common sampling rates, and then resample them if needed (using our fast ASM resampler).
Mmm, i don't think that would be possible. The original Game_Music_Emu library was written in pure C++ code, the files that are not originally distributed with Game_Music_Emu are: emu2413, emu8950, emuadpcm, 281btone.h, 2413tone.h, vrc7tone.h, emutypes.h, msxtypes.h, emutables.h, opltables.h and ymtables.h.
By the way the files ymdeltat.c and ymdeltat.h are not used by any codec, they need to be removed from the patch ;P.
> Are you actually resampling? Our playback engine should be able to take most common sampling rates, and then resample them if needed (using our fast ASM resampler).
Yeah blargg resamples the output of the ym2612 emu to the desired sample rate (this case 44100), i believe that is done to achieve a better accuracy. But i am not sure at which rate the ym2612 operates (52khz?), neither if the resampler (downsampler actually) can be removed.
Yeah, it's 52847.22Hz to be exact, also i don't like blargg's resampler - it cuts that crystallic FM sound :(
Yep, well i didn't really add anything, i just replaced some MAME emulators with GPL'd ones.
> Yeah, it's 52847.22Hz to be exact, also i don't like blargg's resampler - it cuts that crystallic FM sound :(
I'm using the fast downsampler added in gme6pre, maybe using a FIR resampler would result in better quality. But also i'm using
an old ym2612 emulator since the new one (the on from MAME) is not under GPL.
P.S. I noticed that blargg relased SPC emulator library, are you going to include this one too into bundle?
Will upload patch as soon as i finish.
Yes, but only for private builds. And there is already an optimized spc codec for rockbox based on gme, so i thought it wasn't necessary to port it again.
But i still think that re-porting the SPC codec would be a waste of time ;(.
well i don't remember that sfc console itself support reverb effect, about echo, you can activate it manually in spc_codec.h
The current rockbox decoder is already a heavily optimized version of blargg's decoder combined OpenSPC.
>Well yeah but it don't supports reverb\echo effects
No it does. Although some effects are disabled on slower targets. Take a look at spc_codec.h
If sound quality is not better i guess we should stick with the old blip_buffer, if it is better we could keep both versions and enable the old one for slower targets. Please let me know your thoughts about this, so i can get working on the effects code.
P.S. This patch doesn't have the effects support yet, just the new blip_buffer code.
in the previous patch the oversampling was always disabled, so working on the new blip_buffer i fixed that bug, and enabling
oversampling caused a ~20 % speed decrease.
The new blip_buffer does have an impact on the speed test though, but it is very low, around 1-2 %. So i stil have to decide what version
of the effects buffer to use; the old effects buffer adds echo, stereo pan and reverb, and the new one adds stereo pan, echo and surround, and lets you set each value individually.
What do you think?
about the blip_buffer, i think the gme simulation should do like a real machine, instead of add more effects.
ps: we can surely add echo/stereo pan/reverb in rockbox's dsp stage.
surround effect, especially with nes tunes ;).
I really think we should keep these changes, effects are available by default for those who want to test them or
they can be disabled by removing the Sound_set_stereo_depth from each codec or they can be completely removed with the GME_DISABLE_STEREO_DEPTH option in blargg_config.h.
The effects can be adjusted with the Sound_set_stereo_depth (from zero to 1.0), or they can be individually changed with
Sound_set_effects (see vgm.c line 109 and libgme/multi_buffer.h line 18).
Also the speed test only reported an speed decrease of about 10 - 15%, so i don't think it affects performance that much.
if it just act like a post-processing unit, then i still recommend that we can move these thing to the dsp stage
he ask me to do it, here they are:
@tails_, as I remember, the SPC player in Rockbox was ported several
years back, and the author made lots of optimizations so it would run
well even on older devices. It's based on my older OpenSPC-based DSP,
so it doesn't have the accuracy improvements my current DSP has. On my
PowerPC machine, the FM sound chips have always been by far the
biggest CPU users, with SPC significantly lower, so if FM sound chips
work on devices now, a port of the SPC player in gme6pre might be
feasible.
@JoshuaChang, the effects processing is done in GME because it can
operate on the individual sound channels from the sound chips, rather
than the final sound stream. Many systems output mono, so you can't do
as much with a post-effects processor. I agree that such effects
should be entirely optional, and shouldn't hurt performance if
disabled. I partly added them to make headphone listening more
pleasant. The depth control allows a subtle level of effects that
aren't really obvious, but still make it easier to listen to than mono
for a long time.
I agree with blargg, listening to the nes music with the effects enabled is more pleasant especially using headphones,
so i think we should keep them in the patch, they can always be easily disabled in blargg_config.h.
And it might be a good idea to update the spc codec with the new DSP by blargg too.
i've made a quick speed test on cowon d2 target, only tested vgm, for it's the most cpu intensive codec on my target:
gme 0.1
168.45% / 113.98mhz
gme 0.4beta
137.87% / 139.26mhz
gme 0.5
168.93% / 113.65mhz
1) It is based on v03 as the following patch versions do not compile anymore. I will not make the newer ones compilable but aim towards submitting this working patch. The additional optimizations in the synth/buffer stuff can be provided as seperate patches later. This way the changes become more visible and can be reviewed easier .
2) It changes the "regs" definition to "regs_nes" to not collide with other declarations.
3) It removes all "//" comments and replaces them with "/*" comments in the rockbox specific files (apps/codecs/. apps/metadata/.).
4) It removes support for Coleco-SGV for now to not depend upon local BIOS-files which were not proved with this patch.
5) It removes the gme-/blargg-specific metadata add-on (apps/metadata/gme_m3u) for now. This can be provided, discussed and decided in a seperate patch as well.
Edit 1: re-sync'ed against r30225.
Edit 2: Removed residual parts of blargg-specific m3u-handling from rockbox-specific files. libgme path is still untouched.
The RAM usage of NSF was vastly enlarged, the RAM usage of VGM, SGC and KSS is very high as well. As a result I had to disable all of those codecs for low memory targets. For NSF this means we have lost the playback ability for this codec on such targets. Main reason seem to be the arrays in emu2413.c, ym2612_emu.c (relevant for KSS only) and emu8950.c (relevant for KSS only) -- especially tllTable[][][][].
@gama: Are there possibilites to configure these codecs to use less RAM? Most important for me is to support NSF on low memory targets again.
> The RAM usage of NSF was vastly enlarged, the RAM usage of VGM, SGC and KSS is very high as well. As a result I had to disable all of those codecs for low memory targets. For NSF this means we have lost the playback ability for this codec on such targets. Main reason seem to be the arrays in emu2413.c, ym2612_emu.c (relevant for KSS only) and emu8950.c (relevant for KSS only) -- especially tllTable
Yeah those codecs use very large data arrays, will see what can be done about that ;). How can i now exactly how much RAM a codec uses?.
Also in emu2413 we might be able to compute the tl values dinamically as done with the dphase table, but that may have a cpu impact if UPDATE_TLL is called too many times, and we would have to use fixed point math when calculating the tl value.
But then again, is there anyway to get an exact value of how much RAM is being used, and how much RAM can be used in low memory targets?.
@gama: Good to see you're back :) We will need to put some work into this stuff. The nsf codec is not only bigger, but also much slower than the previous implementation. This will be most likely due to the floating point calculations. The emu-code will need to be migrated to fixed point as well for the emulators.
Btw, you can also see details about the codec RAM usage when calling ../tools/codecscan.pl from your build directory.
No problem, i was just taking a break ;).
> We will need to put some work into this stuff. The nsf codec is not only bigger, but also much slower than the previous implementation. This will be most likely due to the floating point calculations.
I'm pretty sure no floating point calculations are done during playback (except for vrc7?), i believe it's slower than the previous codec because the emulation is more accurate and thus has better sound quality. I asked blargg about this, i hope he can share his thoughts about it. Will let you know.
Also maybe the porting process produced some unoptimized code, i must run a speed test comparing the c++ and the c versions to verify that.
With another submit I reduced the gain of the VGM synthesis. This avoids clipping which was present since the first commit to svn. The clipping could be heard when playing "test.vgm" from gama's test files.
My device is Onda VX747, a nice one.
Good job.
still had them included.
By the way i talked to blargg, and he gave some advices about optimization: First he confirmed that no floating point operations are used during playback so we should focus on other aspects as profiling and using IRAM correctly. Currently i'm working on the big arrays from the fm chips.
This is with the "Sonic the Hedgehog (1991)(Sonic Team)(Sega)" set of vgm's.
Regarding floating point you are right. I also reviewed the code and did not find any calculations which are used *outside* pre-calculation of tables.
Please look at line 697 in emu2413.c, UPDATE_TLL function, that's where the tll values are calculated. Unfortunately i will have some time until monday, if you find some free time you can try using fixed point there. Hope it works decently so we can use the same method for emu8950.
To me it seems like the ttl[]-arrays in emu2413 and emu8950 may contain the same data. If so, we can remove one of them, save another 32 KB and may be able to activate KSS and VGM on low memory as well.
The code is a bit ugly, i made it in a hurry. Haven't tested many songs yet either :P, just the Thunder Force IV soundtrack and seems to play
fine (???).
By the way did you tryied the TL_V02_floating_point.patch?, if we use that with fixed point operations we could remove the whole TLL array.
@gama: Do you haveprofiling results? So, information about which parts of the synthesizers consume the most CPU time?
Ok, i will take a look at those then. By the way did the ym2612_no_TL_TAB_v01.patch made any difference?
By the way about KSS, if there is no other solution we can always remove only a couple of chips instead of removing the
whole codec, we could, for example, only remove the emu8950 chip (msxaudio) in the opl_apu files and see if it works in a low memory target.
If you find reasonable options to further reduce memory consumption in the ym2612 tables we might use the slower but memory optimized configuration for low memory targets, and keep the faster configuration for other targets.
Regarding KSS I am leaning towards keeping it as it is. I do not really like to have different feature sets for the same codec on different targets.
By the way the gme_patch_v05 all structs have the largest items at the end, i read somewhere it could help performance a little. That patch also it has some nice changes: fixed a couple of small bugs, replaced all tabs with spaces, it has the latest blip_buffer and multi_buffers, and the optional stereo_effects. So I hope some of that changes make it to the SVN later, we can easily remove the stereo effects for low memory targets. I use that version right now in my sansa fuze v2 with the stereo effects enabled and i really like how it sounds, i'm sure other people will like it too.
1) r30326: Changes to ym2612 emulator, the changed code now selects the fast setting (=tables) for normal targets and the slow (=no tables) for low memory targets
2) r30227: Rest of your patch + enabling VGM for low memory + updating the manual
Thanks!
The next step I am interested in is to bring in the fixes you seem to have included in your gme_patch_v05 version. Can you make an updated patch against latest svn? What in detail is fixed?
And the changes were:
- replaced all tabs characters with four spaces.
- converted all long variables to int as done in the latest version of gme6pre.
- updated blip_buffer and multi_buffer with the latest versions from gme6pre.
- added support for enhanced stereo effects for classic emulators.
- made the necessary changes to all x_emu.c/h files to support the above changes, like correctly calling buffer_set_channel_count, etc.
- moved most of the large items to the end of structures (i remember someone said this could improve performance a bit).
and not really sure but i think i removed some unnecesary code from here and there.
Well making a diff from the latest revision will take some time, especially because of the fixed point changes, but if you are OK with it i can work on it ;).
So.... Just because no one has said anything doesn't mean the feature should be ignored. Please work on it. I'm really looking forward to it! With this codec in SVN, the only format that Rockbox can't play (that I frequently listen to) is PSF.... But those M3U playlists make useability much better for the formats that use them (namely GBS, as it has no real meta-data otherwise).
Last, in case it wasn't obvious, thank you so much for porting this to Rockbox! I can finally listen to VGM/VGZ files on Rockbox! WooHoo! Rockbox has essentially replaced my desktop computer music player now. Mouser X over and out.
Also we are working on making all formats work on targets with small RAM and we are also looking how to optimize the code to use less cpu in some formats like VGM or KSS.
By the way, some time ago i wrote a PSF plugin based on sexypsf, i haven't released it yet cuz i'm working on the gme codecs now. It is in a very beta stage and it would need a LOT of optimizations to be usable i most targets but if anyone is interested just let me know.
Moving to gme6pre, in detail (from your last post):
- converted all long variables to int as done in the latest version of gme6pre.
- updated blip_buffer and multi_buffer with the latest versions from gme6pre.
- made the necessary changes to all x_emu.c/h files to support the above changes, like correctly calling buffer_set_channel_count, etc.
After bringing this in I would like to discuss the residual open points stereo enhancement and m3u-support.
1) Is stereo enhancement available for all codecs? How will this impact performance?
2) The m3u-support looks blargg-specific to me. How will this handling fit into rockbox' playlist handling?
No problem, that's what i thought ;).
Ok, i can start working on the first three steps, if you like. Should i make a different patch for each one?
About the last two questions:
1) The stereo effects are available for all classic emus (NSF, GBS, SGC, HES, KSS and master system VGM). And if i remember well, enabling the stereo enhancement did have an impact in performance; 10 - 15 % decrease in codec speed test. It's not that much and we can always try to optimize it later.
2) Yeah those m3u playlists are more like chiptune specific, it seems the creators didn't follow the official extended M3U specification. So i'm not really sure how could we implement it in rockbox. We would need to find a way to detect the files and parse it accordingly, i think there would be no way to parse the general metadata (the one with # at the start of the file), but maybe we could parse the track (subtune) info. Hope someone take a look at it.
If I understood correctly, the gme6pre changes are kind-of an upstream patch? So, updating rockbox' libgme to the latest gme sources? If so, just provide a single patch that implements this update.
> 10 - 15 % decrease in codec speed test. It's not that much and we can always try to optimize it later.
Well, this will at least hurt for VGM and NSF as those might become problematic for more powerful CPU's (e.g. the nano 2G's) with this change. If you can provide a patch (based on the first gme6pre patch) I will make some measurements on my target.
> Hope someone take a look at it.
Which might take a while :o)
Regarding PSF (yes, slightly out of place here...), I know a guy who got a "working" sexyPSF port on his Sansa e200. It was a few years ago, but what I recall him saying was that the amount of optimization necessary to get it working was unrealistic. For the "slower" targets, perhaps, but I use a Gigabeat S, and I'm reasonably confident that the Gigabeat S could play PSFs fairly well.... Obviously, you'd want to get it working on as many targets as possible. I'm glad to see that someone else it looking into it! That said, I appreciate your work on the GME codecs, and agree that finishing this up is the better idea.
Regarding the M3U support (I didn't realize the implementation was different for GME), would it help at all if the file extension was changed (so as to not interfere with Rockbox's regular M3U reader)? Perhaps instead of M3U, use "*.GME" or something? Just a thought, but if it makes it easier (so that you don't have to much about with Rockbox's M3U parser), I'd say it's a reasonable suggestion. Mouser X over and out.
Edit: Unintended comment Removed (MikeS)
gama over and out. (Mmm, I think i read that somewhere ;))
Here is a list of changes:
- replaced common routines (fading, silence detection, ...) with gme6pre track_filter functions,
and removed the respective variables from all emus.
- updated nes_apu and remaining sound chips with latest versions from gme6pre.
- updated hes_cpu, hes_apu and hes_emu with latest versions from gme6pre.
- replaced almost all long variables with integers.
- updated blip_buffer and multi_buffer with latest versions from gme6pre.
- added some multi_buffer calls in all emus to match gme6pre code.
- fixed update_gain call in sgc_emu.
- correctly call check_end in vgm_emu now.
- replaced hes_cpu_io.h with hes_cpu_run.h.
There are two patches, one without the effects buffer and one with them.
Also with some of the above changes the following files are not needed anymore: nes_cpu_io.h, hes_cpu_io.h and gme_types.h.
Well hope you have some time to try them.
2) You have mentioned a fix of "update_gain call in sgc_emu": Is this fix required for the current svn implementation? If so, can you please provide this fix as separate patch?
3) Which codecs in detail slowed down with -O1?
3.almost every codecs were slow down when using -O1, maybe this only affect arm926 processor?
This *is* defined in blargg_config.h.
Mmm, i'm using the debian-rockbox image with vmware and have no problem compiling both SIMULATOR and real target, so don't know what's wrong ;(.
> 2) You have mentioned a fix of "update_gain call in sgc_emu": Is this fix required for the current svn implementation? If so, can you please provide this fix as separate patch?
Well, it's more an update than a fix. The current codec doesn't handle the update_gain like gme6pre does. They are just a couple of lines actually.
Performance measurements with the provided samples show a reasonable speed up (AY +7%, GBS +5%, SGC +13%, VGM (SN76496) +8%, others +/-0%) with this patch.
Edit: Submitted with r30397-30400, plus several fixes for residual compile issues.
By the way there is quite some floating point math in the effects buffer but it doesn't affect playback, it is used only once when calculating some values.
Anyway there are the small bug fixes descriptions:
- Converted some remaining floating point stuff to FP in nes_apu.
- Correcly set the error_count in the nes_cpu.
- Fixed some missing call to Blip_set_modified in Nes_vrc6_apu
- Correctly set PSG voices in vgm_emu.
- Correctly reset current_track variable in vgm_emu.
- Correctly call Sound_mute_voices after calling Buffer_set_channel_count in nsf_emu.
- in apps/codecs/libgme/nes_apu.c: Apu_enable_nonlinear_() you do not divide the parameter of the first Synth_volume()-call by amp_range anymore. Is this correct?
- wouldn't it be better to comment the whole function as it not used at all?
- what is the new added error_count_ used for? I only see that this is set, but not used.
Yes, that's correct. But i guess we could comment that function, it seems it's an experimental code that is not used by default. I asked blargg
about this one i hope i can get a better explanation from him. I even tested it but not sure about the correct values for sq and tnd.
- what is the new added error_count_ used for? I only see that this is set, but not used.
Ups, i included that one because it is used by the SAP emulator. I wanted to compare the ASAP codec with the one from blargg's gme, but it seems right now the ASAP library does a better job in terms of compatibility, since it supports all types of SAP tracks, and gme only supports three types. But not sure about which one has better emulation and sound quality. So, you can skip that one.
> why not use 12 bit precision, as blargg did?
That is possible of course. Just change FP_ONE_EFFECT to (1LL << 12)
- Add a few comments regarding the size of effects buffers.
Of course, that's easy.
By the way buschel, in case you didn't noticed, in the nsc.c codec file there is an example of how to config each effect individually.
And let me know if there is something else that i can do about the libgme.
I will start working on the PSF plugin again, will try to merge some ARM asm optimizations made by notaz in the SPU code, i hope it works.
P.S. gama, can be older MAME YM2612 emulator used with this codec now?
Technically you shouldn't even do that since you would violate both the MAME license and GPL, so I'm going to ask that you not discuss this here.
FS#11999. Do you see a chance to further debug this?It seems in the vrc7 apu the 2413 emu must run always at the default rate. The vgm_emu plays fine because it uses a resampler after computing the samples from the 2413 emu, so it can use a different sampling rate.
@gama, thanks for fix
By the way i noticed that the value of CHUNK_SIZE defined in vgm.c file is (1024*4) but it shoud be (1024*2) like the rest of the gme codecs, i forgot to change it back when i was writting the codec.
Well, see you soon.
The most important changes are:
- Added support for most of the chips from the vgm format specification version 1.6.0.
- Added support for blargg high quality synthesis in all emus.
- Added support for gme fir resampler in vgm and spc emus.
- Merged the effects buffer support.
- Several updates/fixes to most files.
About the vgm emu new chips, most of them are MAME licensed, so it's obvious they cant make it to an stable release. But there is an option to easily remove them in blargg_config.h. The same for the other two options, they can be enabled or disabled there.
There are two reasons why I updated the library: first, I wanted to make a more complete port from the original sources. And second, I have a very powerfull target, a Samsung YPR0, so I wanted to enjoy the full quality in sound emulation that the library provides. And I can tell you there is a noticeable difference in quality, by disabling the fast synthesis and fast resamplers.
And sorry if I didn't uplad a proper patch file, It's just that since rockobx moved to git, I haven't found the correct way to make a patch ;P.
How do i replace the old default codecs with the new ones? Is there a way to change the default playtime of files? some songs are a tad lengthy and will fade-out before they even finish. Also tagged files like Sega VGM files will fade-out to early. Also tagged playlists won't work.
To replace codecs, just make a full build and extract to the root directory of the player or copy .codec files to /.rockbox/codecs. Personally I recommend the first way so to ensure compatibility.
What is that exactly?
Not something you should be emailing everyone on this task. Go ask in the forums if you need help with the instructions.