Sound question

[OldMan]

Is it possible to play 44KHz audio samples from the adpcm buffer?
I know I can play a cd track directly, and I -believe- the adpcm functions have a max frequency
of 16KHz. Does that mean I *have* to convert a 44KHz sound track to 16KHz/mono/4bit in order to play it????

[Arkhan Asylum]

I thought the chip supported 32kHz?

[OldMan]

From the docs I have, F = 32/(16-DH), which would lead one to believe if DH = 15 ($0f), F=32 KHz.
But the docs also say max for dh = $0E (14) which is 16KHz.

Fwiw, I haven't tried DH= 15 to see if it works.
In any case, it's not 44KHz cd quality, and its looking like I'm going to have to re-sample the audio.

[TurboXray]

I've used 0xf and it works at 32khz. All I have is ver 1.00 of the official docs, so it might be a typo or earlier hardware specification. But the system card routine will take 0xf argument and the ADPCM does play back at 32khz. It even works for ADPCM streaming routine (AD_CPLAY?) from the CD routine, which generates an interrupt from the ADPCM controller so the cpu side can switch the pointer to the new buffer position. Charles tested this as well.

So that's what I chalked it up to - early docs for an early bios.

[touko]

The ADPCM decoder have in fact a large range of frequencies, Huc support only some .

Code Select Expand

$180E   Divider    XT frequency  Sample rate (XT/48)

$00     16         96,270 Hz     2,005.46875 Hz
$01     15        102,680 Hz     2,139.166667 Hz
$02     14        110,020 Hz     2,292.083333 Hz
$03     13        118,480 Hz     2,468.333333 Hz
$04     12        128,350 Hz     2,673.958333 Hz
$05     11        140,020 Hz     2,917.083333 Hz
$06     10        154,020 Hz     3,208.75 Hz
$07     9         171,140 Hz     3,565.416667 Hz
$08     8         192,530 Hz     4,010.8375 Hz
$09     7         220,030 Hz     4,583.958333 Hz
$0A     6         256,700 Hz     5,347.916667 Hz
$0B     5         308,050 Hz     6,417.708333 Hz
$0C     4         385,050 Hz     8,021.875 Hz
$0D     3         513,400 Hz    10,695.8 Hz
$0E     2         770,100 Hz    16,043.75 Hz
$0F     1       1,540,200 Hz    32,087.5 Hz

Personaly, i use 8khz, there is no noticeable difference with 16khz one, but it require 2x less memory.

[Arkhan Asylum]

You will notice diffferences if you're doing something besides SFX, though.   Any really elaborate sounding thing will sound like shit.

44 to 32 should be OK.

44 down to 16 will suck.

[elmer]

From the docs I have, F = 32/(16-DH), which would lead one to believe if DH = 15 ($0f), F=32 KHz.
But the docs also say max for dh = $0E (14) which is 16KHz.

The frequencies for the divisor that touko posted are on ArchaicPixels (presumably from Charles MacDonald's investigations).

The $0E divisor results in feeding the OKI MSM5205 ADPCM decoder a 770KHz clock, with a 16KHz sample output.
The $0F divisor results in feeding the OKI MSM5205 ADPCM decoder a 1.5MHz clock, with a 32KHz sample output.

The thing to note is that OKI MSM5205 is only rated to handle a 768KHz maximum clock frequency.

That's why the System Card BIOS documentation list $0E (16KHz) as the maximum frequency.

The ASIC will allow you to set the divisor to $0F, but by doing so, you are 100% overclocking the MSM5205.

That's certainly not something that's guaranteed to work on all PCE systems, and the analog low-pass filter on the output is going to chop off most of your benefits, anyway, even when it does work.

The OKI MSM5205 document that's also on ArchaicPixels is an interesting read ... particularly the notes about getting the maximum quality output from the chip by offsetting the sample before conversion and avoiding ADPCM overflow.

Personaly, i use 8khz, there is no noticeable difference with 16khz one, but it require 2x less memory.

Ouch!

Either the PCE's low-pass filter circuit was designed for 8KHz and is getting in the way, or you must be using a pretty bad output device.

There should be a pretty major quality difference between the 2.

8KHz is old telephone-quality sound, i.e. fine for voice, but poor for music.

16KHz should be a lot better (at least for music).

[touko]

Hear that :

8khz voices, i think it's not bad at all and sounds more than decent for me,and the quality difference with 16khz is negligible .
If you use good samples,even at 8khz you keep a very good quality and using 16 khz or more is useless,unless you want to eat your adpcm RAM quickly, or if specific high quality is required .

[elmer]

8khz voices, i think it's not bad at all and sounds more than decent for me,and the quality difference with 16khz is negligible .

The quality on those sounds fine ... you're not needing the extra high-frequency headroom that you'd get by going to 16KHz on those samples.

Sounds like you've got a couple of "clicks" in there that you could remove, but otherwise, they sound nice.

[OldMan]

Thx elmer.
So the adpcm is seperate from the cd stuff. I kinda thought so, but it's nice to have confirmation.
Guess I can't just read the incoming cd audio, save it, and pump it back out via adpcm <sigh>
(Oh, all right. I -can- do it, but it would require conversion in the pce. Not worth it)

[touko]

Sounds like you've got a couple of "clicks" in there that you could remove, but otherwise, they sound nice.

in-game samples (for player and opponent) are pcm only (5bits @6.992khtz), and clicks were removed(it's an old version here,and samples were ripped from various snes games  ),only the master's voice is adpcm .

[TurboXray]

Thx elmer.
So the adpcm is seperate from the cd stuff. I kinda thought so, but it's nice to have confirmation.
Guess I can't just read the incoming cd audio, save it, and pump it back out via adpcm <sigh>
(Oh, all right. I -can- do it, but it would require conversion in the pce. Not worth it)

What were you trying to do?



 As for the MSM5205 chip not handling wrap around, it can be an issue if the conversion app doesn't handle this. I've always used SOX utility to compress to ADPCM, but I'm not sure if that app is taking this into account. IIRC, the MSM5205 decompresses to a 12bit value, but only the top 10bits are output to the DAC. A common work around for the wrap issue was to just lower the volume on the input sample, or write an app to pick out near edge amplitude samples. The lower volume method results in less quality though.

Ryphecha's software ADPCM driver decompresses to 13bits, but corrects to 12 bit and outputs to 10bit.

[OldMan]

What were you trying to do?

Not at liberty to discuss details.

Suffice it to say, -if- I could read pcm from the cd (which can be done), buffer it, and then play it via the adpcm chip (which we can't , we would have much higher quality audio in....something.
As it is, I have the conversion routines (No, sox is not an option for....reasons) and am currently testing that part.  I'm just not sure 8/16 K will satisfy Arkhan.....

Fwiw: Did you know that the only -major- differences between ADPCM types is the step tables they use? Google-chasing things from archaic pixels led to the dialogix specs, which had the encoder algorithm and tables.....
Which made for an easy conversion of the generic adpcm routine I was using.

[TurboXray]

Suffice it to say, -if- I could read pcm from the cd (which can be done), buffer it, and then play it via the adpcm chip (which we can't , we would have much higher quality audio in....something.
As it is, I have the conversion routines (No, sox is not an option for....reasons) and am currently testing that part.  I'm just not sure 8/16 K will satisfy Arkhan.....

Ahh man, now you're just teasing - lol. I know you don't want to give away too much details, but how much cpu resource do you have to throw at this? I might have an alternative for you.

 Also, and maybe this has nothing do to with your project, but that Warriors of Fate prequel game on the PCECD - runs game logic every other frame, and reads CD data in between those frames to stream level data to the game (background tiles as the game scrolls).

 Alternatively, I've seen 4bit ADPCM that isn't like IMA or others, but instead is like the SNES method. It's much faster to decode too. It's basically range compression with the 4bit delta being similar to u-law audio, but the audio is segmented into blocks with a range multiplier set for each block. A block could be something like 16 or whatever amount of samples. I've also seen it where the 4bit isn't a delta, but a direct offset with the block mutiplier (though it's no longer "delta" pcm).

 Now I'm just babbling on. I love this kinda stuffs

[elmer]

Suffice it to say, -if- I could read pcm from the cd (which can be done), buffer it, and then play it via the adpcm chip (which we can't , we would have much higher quality audio in....something.

Is there some reason that you don't want to just store the pre-converted ADPCM in the data track, load it directly from CD into the ADPCM buffer, and then play it from there? 

Fwiw: Did you know that the only -major- differences between ADPCM types is the step tables they use? Google-chasing things from archaic pixels led to the dialogix specs, which had the encoder algorithm and tables.....

It's a pretty-simple basic algorithm, isn't it?

Have you seen ...
"Microsoft Multimedia Standards Update - New Multimedia Data Types and Data Techniques (Apr 15 1994, Rev 3.0)"

That's a nice reference document.

I coded a couple of different formats many years ago (Microsoft ADPCM and IMA ADPCM), and did my own little variation of Microsoft's code that I seem to remember got used once-or-twice.

A quick bit of research shows that Dialog/VOX ADPCM is just a cut-down version of the IMA ADPCM algortihm ...

http://wiki.multimedia.cx/index.php?title=Dialogic_IMA_ADPCM

I'll have to dig out my old audio-converter source and see about updating it to add the Dialogic/PCE format and then also see about releasing it as open-source.

Also, and maybe this has nothing do to with your project, but that Warriors of Fate prequel game on the PCECD - runs game logic every other frame, and reads CD data in between those frames to stream level data to the game (background tiles as the game scrolls).

I didn't know that anyone was actually doing streaming on the PCE, that's cool! 

Alternatively, I've seen 4bit ADPCM that isn't like IMA or others, but instead is like the SNES method.

That sounds more like Microsoft's ADPCM, which is why I used a modified version of that when I wanted something with really fast ADPCM decompression.

Now I'm just babbling on. I love this kinda stuffs

Me, too. 

[OldMan]

Ahh man, now you're just teasing - lol.

Yeah, sort of. If you think about what Aetherbutt is doing, and recent messages from me, you can make a pretty good guess as to what I'm doing. Remember, I'm the tool guy here.

...runs game logic every other frame....

I'm hoping it doesn't come to that.

Is there some reason that you don't want to just store the pre-converted ADPCM in the data track, load it directly from CD into the ADPCM buffer, and then play it from there? 

It's a matter of quality. I have to be able to say to the boss "This is why we can't do it that way" and then convince him that What I'm doing 1) Will work, and  2) Will work good enough.

There's also some technical stuff that prevents using sox.

It's a pretty-simple basic algorithm, isn't it?

Laughably so. When I saw it, it took less than an hour to get it working. Biggest problem was I had the wrong (intel/dvi) table. Once I figured that out....it works.
I just thought it noteable that the only real change to the algorithm (for different formats) was the tables used. Maybe I should compile a set of tables to output different formats...

[ccovell]

I just thought it noteable that the only real change to the algorithm (for different formats) was the tables used. Maybe I should compile a set of tables to output different formats...

Got any tables for NEC uPD7759C ADPCM formats?  :-D  Seems nobody has those.

[OldMan]

Got any tables for NEC uPD7759C ADPCM formats?  :-D  Seems nobody has those.

A quick look says the tables diff table at least is calculated on they fly, apparently.

See if this helps: https://github.com/xobs/chumby-mame/blob/master/src/sndhrdw/upd7759.cpp

[elmer]

See if this helps: https://github.com/xobs/chumby-mame/blob/master/src/sndhrdw/upd7759.cpp

Looks like ...

http://coinops.googlecode.com/svn/trunk/CoinOps/MAME/src/sound/upd7759.c

and ...

https://github.com/vgmrips/vgmplay/blob/master/VGMPlay/chips/upd7759.c

... may be a bit newer, with more info.

It looks like a bit of a monster. 

[Arkhan Asylum]

I can't wait til I'm old and have tons of free time, lol