Which sound format uses CPU the least?

[r00tb33r]

I'm thinking of adding music support to rockdoom and would like to know which sound format would use the least CPU cycles.
I'm thinking WAV, but I would also want to know the optimal bitrate and sampling rate that would require the least conversion (basically a sound map that can be fed directly to the interface, without a codec).
Any ideas?

[saratoga]

The playback engine runs at 44.1kHz. 

[dreamlayers]

Plugins can use any available sampling rate.  Rockdoom uses 11025 Hz when that is available.  Otherwise it uses 44100 Hz.

[r00tb33r]

Plugins can use any available sampling rate.  Rockdoom uses 11025 Hz when that is available.  Otherwise it uses 44100 Hz.

How do I know which sampling rate say Gigabeat rockdoom uses?



...
There might be a slight problem with WAV as I have just converted the Doom 2 music I had to 16bit @ 44100Hz and it came out as 783MB total, which is likely unacceptable to most people.

How CPU intensive is MidiPlay?  Ideally from software design standpoint the port of doom should rely on the resources in the WAD, but how likely is it that the midi patchset(s) we have will produce decent sounding result?
The recordings I have were recorded from a Roland MIDI card which sounds pretty much ideal, but the size in WAV format is unacceptable.

I gave the Doom 2 MIDIs a listen with the patchset available on the MidiPlay wiki page, and it does sound like Doom music, but well, unsatisfying.  Sure this might be sufficient to add support for MIDI music in doom, but I would prefer to try some more patchsets.
A quick Google search returned a ton and a half of dead links...  Anyone know places to get patchsets?

[dreamlayers]

How do I know which sampling rate say Gigabeat rockdoom uses?

You can look at the configuration header file for your player.  For example, if you mean Gigabeat F, that would be firmware/export/config-gigabeat.h.  There, search for HW_SAMPR_CAPS.  For the Gigabeat F, that is:

Code: [Select]

#define HW_SAMPR_CAPS (SAMPR_CAP_88 | SAMPR_CAP_44 | SAMPR_CAP_22 | \
                       SAMPR_CAP_11)

SAMPR_CAP_11 means 11 KHz, or more accurately 11025 Hz.  Since that is present, Rockdoom will use it.  If it wasn't there, Rockdoom would use 44100 Hz.   

There might be a slight problem with WAV as I have just converted the Doom 2 music I had to 16bit @ 44100Hz and it came out as 783MB total, which is likely unacceptable to most people.

Well, you could resample it and cut the size to 1/4 of that.  Considering the number of tracks and how Doom only needs 8 MB RAM on a PC, a target with 32 MB might even have enough memory to load the whole track at once.

I'd still rather see compression.  FLAC is rather fast, see:
http://www.rockbox.org/twiki/bin/view/Main/CodecPerformanceComparison
Shorten (SHN) ought to be even faster and simpler to decode.

I can't answer the question on MidiPlay, because I've never used it.

[r00tb33r]

How do I know which sampling rate say Gigabeat rockdoom uses?

You can look at the configuration header file for your player.  For example, if you mean Gigabeat F, that would be firmware/export/config-gigabeat.h.  There, search for HW_SAMPR_CAPS.  For the Gigabeat F, that is:

Code: [Select]

#define HW_SAMPR_CAPS (SAMPR_CAP_88 | SAMPR_CAP_44 | SAMPR_CAP_22 | \
                       SAMPR_CAP_11)

SAMPR_CAP_11 means 11 KHz, or more accurately 11025 Hz.  Since that is present, Rockdoom will use it.  If it wasn't there, Rockdoom would use 44100 Hz.

What's the advantage of 11KHz on a target as fast as Gigabeat?  It doesn't actually sound too good at all.  Anything less than 22KHz causes a very noticeable degradation in sound quality.  Why not use the sampling rate of the original sounds?
According to http://doom.wikia.com/wiki/Sound some Doom sounds have a sampling rate of 22KHz, which explains the degradation I noticed.
It shouldn't be too hard to force a higher sampling rate right?

[dreamlayers]

What's the advantage of 11KHz on a target as fast as Gigabeat?  It doesn't actually sound too good at all.  Anything less than 22KHz causes a very noticeable degradation in sound quality.  Why not use the sampling rate of the original sounds?
According to http://doom.wikia.com/wiki/Sound some Doom sounds have a sampling rate of 22KHz, which explains the degradation I noticed.
It shouldn't be too hard to force a higher sampling rate right?

It's very easy to force a higher sampling rate.  Look near the start of apps/plugins/doom/i_sound.c.  In particular, this decides the sampling rate at compile time:

Code: [Select]

#ifdef HW_HAVE_11
#define SAMPLERATE  SAMPR_11 // 44100 22050 11025
#else
#define SAMPLERATE  SAMPR_44 // 44100 22050 11025
#endif

I feel that sound in plugins skips too easily, even when the CPU is fast enough.  Regardless, you ought to be able to do 22 KHz on a Gigabeat F.

[r00tb33r]

What's the advantage of 11KHz on a target as fast as Gigabeat?  It doesn't actually sound too good at all.  Anything less than 22KHz causes a very noticeable degradation in sound quality.  Why not use the sampling rate of the original sounds?
According to http://doom.wikia.com/wiki/Sound some Doom sounds have a sampling rate of 22KHz, which explains the degradation I noticed.
It shouldn't be too hard to force a higher sampling rate right?

It's very easy to force a higher sampling rate.  Look near the start of apps/plugins/doom/i_sound.c.  In particular, this decides the sampling rate at compile time:

Code: [Select]

#ifdef HW_HAVE_11
#define SAMPLERATE  SAMPR_11 // 44100 22050 11025
#else
#define SAMPLERATE  SAMPR_44 // 44100 22050 11025
#endif

I feel that sound in plugins skips too easily, even when the CPU is fast enough.  Regardless, you ought to be able to do 22 KHz on a Gigabeat F.

Perfect!  SAMPR_22 sounds much better.  No reason for higher sampling rate since the WAD does not contain sounds of higher sampling rate than 22KHz.

Do you know how/why/where RockDoom stops music playback?  I have low bitrate mp3s that I would like to hear playing to see if Gigabeat F can handle both.
Thanks so far!

[Llorean]

It stops playback because there's not a system for sharing the playback buffer. Doom needs more of the RAM than the normal amount plugins are allocated and it's an all or nothing deal.

[nls]

How CPU intensive is MidiPlay?

I'd guess only the gigabeat f and s would be fast enough to play midi with midiplay while running doom. (it's rather cpu intensive and only barely realtime on some targets)

[dreamlayers]

Perfect!  SAMPR_22 sounds much better.  No reason for higher sampling rate since the WAD does not contain sounds of higher sampling rate than 22KHz.

You're right, on some sounds (eg. breath sounds) I can hear an improvement.  However, on the 5G iPod, SAMPR_22 causes crackly underruns.  So, that #ifdef block should probably be changed so that quality isn't needlessly reduced on fast targets.

Doom resamples some sounds to vary their frequency.  (I think it has something to do with the current health level or amount of damage sustained at once.)  Because of this, even 44.1KHz might improve quality.

Be careful with how you introduce music.  It's probably easy to cause buffer underruns.  I guess ideally the sound code should be changed so get_more simply returns data which has already been calculated instead of doing the calculation itself.  On PP502x, the the COP might be of use here.

[r00tb33r]

I think I understood what Llorean said, RockBox does not have mixing, and therefore not able to mix music playback and doom sound effects.  Am I correct?
So would music playback/mixing have to be implemented in doom?
Also...  Sounds like there was some work done but it got lost along the way...
http://forums.rockbox.org/index.php?topic=9632.msg74201#msg74201
Was he referring to MIDI or the normal music playback in RockBox?
Either way I'd like to hear suggestions about implementation.

[dreamlayers]

Doom has a mixer which you could maybe use.  Look at i_sound.c.

[AlexP]

I think I understood what Llorean said, RockBox does not have mixing, and therefore not able to mix music playback and doom sound effects.  Am I correct?

No, that isn't what he was saying.  Each device has a set amount of memory, which Rockbox splits into various chunks - a small chunk is reserved for plugins, and a much bigger chunk is reserved for music playback.  Doom requires more memory to run than is available from the small plugin chunk, and therefore it also "steals" the large playback chunk.  As Doom has now taken the large playback memory chunk, playback is no longer able to work.  It is about memory usage, and not the ability to mix different audio.

[r00tb33r]

I think I understood what Llorean said, RockBox does not have mixing, and therefore not able to mix music playback and doom sound effects.  Am I correct?

No, that isn't what he was saying.  Each device has a set amount of memory, which Rockbox splits into various chunks - a small chunk is reserved for plugins, and a much bigger chunk is reserved for music playback.  Doom requires more memory to run than is available from the small plugin chunk, and therefore it also "steals" the large playback chunk.  As Doom has now taken the large playback memory chunk, playback is no longer able to work.  It is about memory usage, and not the ability to mix different audio.

So if playback code was put into Doom, won't they be able to share it?