48kHz direct digital output

[jmarshall]

hi all,

i've just implemented preliminary 48khz direct digital output of pcm streams (and anything that decodes to 2 channel 48khz pcm such as mp3/ogg/flac/aac etc. etc.) into cvs.

this is an experiment to see whether adding our own high quality 44.1khz -> 48khz upsampling is worth the cost in terms of coding and the cpu performance hit.

i need people to test the quality of this.

to participate, please first obtain the ssrc.exe tool (windows command line tool) from here:

homepage of ssrc resampler program (http://shibatch.sourceforge.net/)

next, do the following:

1. get a good cd track you wish to use for testing the quality.

2. rip it using eac or something you're confident with to .wav format.

3. next, run it through ssrc with the options:

ssrc --rate 48000 in.wav out.wav

you could add --dither 3 or 4, and --pdf options if you wish to see if these make a difference.

4. copy both files to the xbox and check you have dd/dts passthrough enabled (and digital out!). note you don't have to have a dd/dts decoder - just pcm is fine.

5. play both tracks - see which one you like the sound of better and report back here. note that you should be able to tell that the 48khz one is being direct passed through by watching a viz - not a lot should be happening if all is working.

note that i encoded both my files with flac in order to reduce the size and also i had a bit of trouble with .wavs causing crashes at the end of the track.

let me know how it goes. note that the direct digital output track has been attenuated by mplayer on playback in order to match the output from the mcpx audio processor on the xbox - this will, if anything, reduce the quality and dynamic range of the 48khz file.

i have tested norah jones "don't know why" but could not determine a significant difference, though i think i prefered the direct passthrough method. this may be because i was expecting it to be better, though!

let us know how it goes.

cheers,
jonathan

[pike]

i will test this later today!

like i wrote here (http://www.xboxmediaplayer.de/cgi-bin/forums/ikonboard.pl?act=st;f=4;t=2083) ssrc is the way to go. low cpu usage and one (if not the) best resamplers available out there.

[MrMario64]

great, i will test this today to..
(though i will install an xboc with xbmc at a friends house to so hope i have the time ;) )

[thebeast]

i wish i could test this, but i don't have digital output add-on or cool audio hardware yet. it sounds great though, lets squeeze everything audio out of the xbox hardware, that is possible.

and then a little more ;)

[Butcher]

i will test this later today!

like i wrote here (http://www.xboxmediaplayer.de/cgi-bin/forums/ikonboard.pl?act=st;f=4;t=2083) ssrc is the way to go. low cpu usage and one (if not the) best resamplers available out there.
only worth it if it's better than the mcpx though - as that is effectively no cpu.

[pike]

when we enabled passthru for dd, the difference was -very- noticeable

[Butcher]

true, but a dd resample is different from pcm stereo. ;)

[pike]

ok, i _attempted_ to do the test but it was not possible due to:

the 44khz one, no problem (as expected)
the 48khz one, didnt make the slightest *beep*

it doesnt help that settings;music is quite "screwed up" at the moment http://www.xboxmediaplayer.de/forums/non-cgi/emoticons/wow.gif

[pike]

true, but a dd resample is different from pcm stereo. ;)
yeah, atleast 2steps less, no decoding/encoding (unless output to all speakers naturally)

[Gamester17]

[14:43] <poing> i'm not sure if a change jcmarsha comitted was intended to work like that, or if it's a bug
[14:43] <poing> stereo 48khz material is always output with passthru now
[14:44] <poing> ignoring the stereo passthru yes/no optionsound like a bug to me (sorry i don't have external amp/decoder so i can't test or confirm this, wish i had/could though)

[pike]

i'm starting to think my decoder doesnt like 48khz pcm streams... can't get passthru to work

[jmarshall]

pike: a lot of music dvds are 48khz pcm - do these work for you?

also, try viewing a viz while playing the 48khz track - it shouldn't do much (fountain.vis just has a single solid curve coming out from the centre that goes around and around the screen for instance).

gamester: poing has fixed that small discrepancy so that it only passes through now if the dd stereo pass through is enabled. (obviously this option is now misnamed though :). once we've determined whether our own upsampling is worth it or not, i'll look at overhauling the options so they are a bit more clear.

cheers,
jonathan

[jmarshall]

the only advantage i see currently with doing the software upsampling currently is the 6db hotter output. if this can be achieved through the mcpx though, it will be negated.

i find no obvious quality difference, though i'm going to get some better samples for testing before i make my final conclusion.

cheers,
jonathan

[Butcher]

try idirectsound8::setmixbinheadroom for boosting the output by 6db. ;)

[jmarshall]

thanks butcher - after the discrepancy in volume came out to almost exactly 6db, i figured that the mi***** process was leaving some headroom in there somewhere. will try it out tonight.

i got a "killer" sample from hydrogenaudio.org that i'll test when i get home - makes it easy to detect poor upsampling and/or clipping. will see how it goes tonight.

cheers,
jonathan

[Butcher]

yeah i think the stream headroom is set to 0, but i'm fairly sure the mi***** headroom is default.

[pike]

@ j

i tested a dvd-video with stereo pcm 48khz and passthru didnt work for that one either.

my receiver is in the "middle class" and it has a builtin dvd player. the same dvd-video plays fine on the unit.

do you send that audio untouched, or is it re-padded or something?

[Blackwolf]

i have been unable to make anything 48khz 2 channel play since this recent addition. i have tried xvid/divx/wav/vob
all of them i get silence. however when i switch to analog output or i disable dd stereo pass thru it works fine

[jmarshall]

ok, i was setting a flag incorrectly (as encoded, instead of pcm). it worked fine on my receiver, so obviously some are different.

please try the new version in cvs now.

also, i've added butcher's suggestion and now the mcpx route is coming out at full volume whereas it used to have 6db of headroom. this means that all audio coming out, either through the mcpx or through the ac97 route will now be the same level.

i've also come across a killer sample for testing the quality of upsampling.

this file contains some low-level phone dialtones modulated on a very strong 19khz pure tone. the result is that if upsampling is not working too good, then you get "alien" type noises. if the upsampling is working well, then you'll just hear the dialtones.

note that due to the high amplitude, high frequency tone, this sample should be used very carefully.

i suggest that you try it out using headphones with the volume low so that you can recognise what the alien effect sounds like. this sample has the potential to burn out tweeters in poorly designed tweeters.

what it will sound like if the upsampling is working:

dial tones plus you may feel some pressure (start get a headache) if your speaker system passes the 19khz tone well - you probably won't hear the tone, but it is very loud, so you'll feel it if the volume is high enough.

what it will sound like if the upsampling is not working:

dial tones plus "alien" type interference.

what it will sound like if it's clipping:

dial tones plus loud "laser" type sounds.

the file can be obtained here:

udial upsampling test tone (http://www.massey.ac.nz/~jcmarsha/xbox/udial.zip)

there are 2 flac files in the .zip.

udial.flac - original 44khz sound
udialssrc.flac - same sound upsampled to 48khz using ssrc

the .zip file is password protected. the password is:

dontplayloud

you should be able to easily tell the difference when using xbmc.

please try the second file with the dd stereo pass through both on and off, and let me know how it works.

cheers,
jonathan

[pike]

nice samples!!

naturally passthru is fine with the ssrc one, weird is, it's fine even when passthru is off.

the non ssrc'ed one always plays with the upsampling artifacts.

conclusion, the mcp-x doesnt re-sample already 48khz audio?!

[MrMario64]

well, on my receiver they both sound the same including with pass through on or off.

they both play with a sound of a "siren" through it.
dunno if you would call that a laser or alien :)

it does upsample, cause the viz is doing nothing on the udialssrc version with pass through on.

sidenote, in a diff thread i posted the problems about &%&^% sound n the beginning of each song. when i select digital out and no passthrough i do not get the &^%&^ sounds. (with this version)

[Butcher]

48 to 48 doesn't require any resampling so the samples are just passed through as is. dsps are digital - if there is nothing to be done to the sound they don't change it at all.

[Butcher]

test, i get the siren on the first sample on both settings and no siren on the second on both settings.

[jmarshall]

thanks for the testing, guys.

butcher:

yep - when it's 48khz already, the only upsampling done is to 24bits then down to 20bits after it does the dsps. (that's why 48khz dd/dts is still destroyed by the mcpx)

i think the best method quality-wise is to upsample in software using ssrc, then pass the resultant 48khz stream through the mcpx. this allows us then to do volume attenuation easily, as well as further eq or whatever.

obviously, this will be an option. most users probably can't tell the difference on normal music, so will prefer to not have the cpu overhead of the software resampling.

mrmario64/others:

try turning digital output off, and play the ssrc'd sample through the analogue out. you should only hear the phone dialtones.

now i'll look at the ssrc.exe code, and encapsulate it so that it's a bit more useable for xbmc.

cheers,
jonathan

[MrMario64]

i think i can blame my speakers for the siren on the 44.1khz sample.

on analog i get no siren on 44.1 but i do get siren on 48 sample then.

my speakers each have their own dsp, then da and then the amp.
so , my speakers prolly make every signal 48 and thats why i get the screwup.

[pike]

a thought... visualizations only work with passthru disabled at the moment, that's a flaw in my eyes. (guess the problem is mplayer?)

would it be possible to send a stream that the vizes can work with also?

[jmarshall]

pike - reason is that the data isn't being sent to the viz as we're using ac97. once i get the 48khz upsampling finished and working, i'll implement it so that it goes through directsound and the xbox mcpx - that way we'll get the viz back, and we can also do volume control/eq etc. in the mcp.

will let you know when i get upsampling going.

[jmarshall]

okay, 48khz upsampling is in cvs now.

it's currently disabled by default, due to the fact that i didn't have time to do a gui option yet :)

run xbmc once, and get it to resave settings.xml (change a setting then change it back)

then edit e:\tdata\0face008\settings.xml and change the <highqualityresampling> option to true.

all non-video, non-48khz stuff should be upsampled.

turns out that mplayer has this functionality built in :)

note that i'm not using the highest quality setting yet (it uses integer based polyphase filters) but it passes the udial.flac test.

please take a listen and post your opinions.

cheers,
jonathan

[pike]

so not ssrc? u know one of the reasons ssrc was developed was because it has a nice compromise between quality and cpu usage ???

anyway, i was thinking, could the "output to all speakers" also benefit from this? ie that audio gets upsampled b4 sent to mcpx (?)

[pike]

oh and btw, "all non-video" only? why not 44.1khz mp3 audio in videos also? (just an example)

[jmarshall]

i disable videos because i was worried about the performance hit. perhaps a separate option could be implemented here. most video sources are 48khz anyway, so i don't know how useful this would be.

yes, if output to all speakers is enabled, then upsampling still applies.

the reason i didn't go with ssrc is due to the way that we are handling the audio buffers. i'm not 100% sure, but i believe that mplayer likes to know how much audio data it can send (ie how much space we have in the audio buffer that is not already sent to the mcpx) and also likes to know what size chunks to send. the problem with ssrc is that it reads in varying amounts of data based on where it is in the upsampling process (effectively oversampling the data). thus, we'd have to keep a separate buffering system in place to hold the currently resampled data, and the yet to be resampled data. this gets messy, and involves quite a bit of memory shuffling.

once i found out that mplayer could do it directly, i figured i'd test it out, and seeing as it passed a few of my tests, i figured it was good enough for now.

once others have tested, we should get a better idea of how it compares to ssrc. note that 48khz is still passed direct (no upsampling needed, ofcourse) so you can compare the mplayer upsample to a 48khz ssrc upsampled version easily enough.

i've kept the code i've done so far for ssrc, so if we need to go back to it, we can.

cheers,
jonathan

[pike]

btw, does this also work for cdda? i've just compiled a build and will test shortly

[jmarshall]

no - only mplayer currently.

i'll have a bit of a play with a buffering method for ssrc this weekend. it's just a matter of balancing the amount of data given to us by mplayer and the amount that we output (which are ofcourse different when we're resampling.)

the problem i think is that mplayer is not designed with only audio in mind. when you just have audio, all you have to worry about is just keeping up with the output rate. when video is added to the mix, then things get quite a bit more complicated!

the ultimate would be a standalone audio core.

[pike]

hear hear!

someone (*cough*) oughta look into porting foobar. can it get any better? i think not.

[mvoosten]

should this potentially mean dts audio cd's should finally work?
for now, xbmc doesn't recognize the higher sample wav's. maybe we should just add another extention to it to differentiate between a 41 and 48k wav?

[pike]

@ mvoosten, at this moment, no.

we still lack a dts audio decoder, if you happen to know of a non alpha opensource one, please let us know

[mvoosten]

mmm, but pike, when you play a dts encoded movie, that just outputs fine as a dts stream, so why should we need a seperate audio decoder to get dts wav's to work?

[pike]

reason is simple we can output dts streams from movies - they are in 48khz where's dts audio cd's are in 44.1khz. the xbox hardware can only passthrough 48khz unfortunately. thus the dts audio cd's would need to be decoded to pcm before we could output it :(

[mvoosten]

not enirely true...
a lot if dts audio cd's are 48khz and not downsampled to 41khz.
for example see this list of available titles: http://consumers.umusic.com/dvda/releases.html

m.

[jmarshall]

those albums you listed are either sacd (super audio cd) or dvda (dvd-audio).

dts audio cds are different. they can only be 44.1khz. what happens is that the 5 44.1khz streams are encoded to a dts 44.1khz stream and then popped onto a cd. it can then be played by any cd player with a digital output. a dts receiver will recognise that it is a dts stream and not a pcm stream and decode. they have to be 44.1khz to play back in a regular cd player.

one thought i had was packing out the stream with zeros and see if that works. (i believe this is what is done on dts tracks recorded at 768kbits/s, but i may very well be wrong!)

i certainly don't have time to play around with this at the moment though.

[MrMario64]

jmarshall, i hope you won't forget about being compatible with 2 channel digital out?
i hope the &^%& sounds at the start will go away for me after you did all this stuff.
this is not just because i have a 2 channel receiver, but it would allow digital recordings on cd, minidisc, dcc, mp3 players etc.

[jmarshall]

an update:

i've just committed the latest version to cvs.

now we're using ssrc code instead of mplayer. seems to be working fine.

i've added a gui option in settings->music which allows you to turn it on for music only, or for both music and videos.

we're currently running things through the mcpx still - means we get volume control in hardware, plus ability to eq or whatever at a later date.

still doesn't work for cd playback - reason is that the directsound stuff for that is buried within cdrip.lib. i'll rip it out of there and put it within xbmc so that it's handled the same way. that'll take a wee while though.

please test the new version and let us know how it works!

mrmario:

i'm still not 100% sure what is going on with your system. it may be due to the 6 channel opening up asyncdirectsound() with mi***** set so that it tries to output ac3. seems bizarre that it allows it though, given that i assume you have ac3 and dts disabled in the ms dash. perhaps you could force it to not open asyncdirectsound in audio.cpp if the number of channels is more than 2. that'll help narrow it down.

[MrMario64]

well, i do have dd enabled in msdash cause otherwise i could not do those tests for you (it does not allow passthrough then).
with dd not turned on i do not get the ^^&%&^ sounds, but it does not passthrough.

however, it should not be a problem since mod, sid etc play fine with this setting. only stuff played with mplayer does this.

i would be happy to disable the dd ,wich would make sence since i do not have dd, if i can enjoy the 48khz upsampling then and that i know the digital out is still in full use (like 2channel passthrough since xbmc says analog).

if you can clarify it would be great.
good job jmarshall!!

[Butcher]

mod and sid never passthrough - they have their own sound output code that is separate from the mplayer stuff. the mod stuff in particular uses the mcpx to do all it's resampling and mixing so i can't pass through (and no, we can't software resample mods, 100 channels is too much for the xbox cpu).

[pike]

i've noticed that while playing music there's no output to the visualizer, is this something you will look at also?

:d

[jmarshall]

mrmario64:

is your receiver capable of ac3? if not, turn off "enable ac3" in the ms dash.

the high quality resampling method is not direct pass through. what is happening is we are bypassing the mcpx's upsampling by doing it first in software. the rest of the mcpx chain is still being used. this has no noticeable (to me, anyway) detrimental effects, while it enables a number of benefits such as volume control and eqing at a later date.

so: you don't need pass through enabled - that is just for ac3 and dts tracks.

to test, use the udial.flac file above. you should clearly tell the difference between the resampling methods.

also, i'll be moving the cddaplayer code over to use the same method tonight if i get time.

cheers,
jonathan

[pike]

btw j... a friend tipped me that p.p. (foobar2000) has optimized ssrc ~100% in foobar. sources are available

i tried to play a svcd with resampling on for videos and it wasnt fluent.

[jmarshall]

ssrc uses quite a bit of cpu.

i've seen the fb2k sources, and they're not majorly different. not sure of the licensing of those, anyway.

part of the reason fb2k may work faster, is that they've taken the conversion from short->float/double->short out of the equation (everything runs in floating point up until output to the audio device). other than that, there's not a lot that is different that i could see. just optimized for foobar's method of passing data.

cdda resampling is also in - seems to be working fine.

agreed with the cpu hit - it's bigger than i thought it would be.

most videos i have are 48khz, so no resampling to worry about.

[Butcher]

depending on the operation, floats are faster than shorts anyway. for addition or subtraction the shorts are quicker, but multiplication, division and more complex stuff tends to be faster with floats. also, is any sse/mmx being used? if not they could help, or maybe even using pixel/vertex shaders.

[jmarshall]

butcher:

i'm not up with the play on sse/mmx stuff, so i have no idea how to optimise for this sort of stuff.

i'm sure it could be optimised quite a bit yet. for instance, there's quite a a few conditionals that could be taken out of loops etc. not sure how efficient the compiler is at sorting that sort of stuff out.

feel free to look through the code in ssrc.cpp if you have some free time!

i'm off to google on optimising for sse/mmx.

cheers,
jonathan

[Butcher]

handy docs: http://www.intel.com/design/pentium4/documentation.htm
they're for p4, but if you stick to the sse stuff rather than sse2/3 you should be fine.
also: http://ulita.ms.mff.cuni.cz/pub/techdoc/
that has copies of the old p3 docs.

[jmarshall]

thanks.

found a couple of other tutorials as well with some basic intro stuff.

not sure of the performance hit (if any) of going from normal mode to sse and back. reason is that the fft stuff is probably not all that suited to sse (or perhaps it's more correct to say that i don't want to convert it :) though the application of the filters definitely is (run through array of floats, multiply by another array + add type of stuff).

if i get a chance i'll have a bit of a play and see what i come up with.

[---=Snyper=---]

something to look into..

the 48khz seems to work great.. my sony es reciever shows that its doing 48khz.

but ive found that when you have 48khz enabled.. when you play a shoutcast streams and then goto the visuals the music slows down.. only when you are viewing the visuals.. while just in the menus and while the screen saver is on shoutcast plays fine.. turn off 48khz everything works fine..
mp3s on my hd and smb, cdda dosnt not have this problem. they play fine..

snyper

[Butcher]

thanks.

found a couple of other tutorials as well with some basic intro stuff.

not sure of the performance hit (if any) of going from normal mode to sse and back. *reason is that the fft stuff is probably not all that suited to sse (or perhaps it's more correct to say that i don't want to convert it :) though the application of the filters definitely is (run through array of floats, multiply by another array + add type of stuff).

if i get a chance i'll have a bit of a play and see what i come up with.
there's essentially no hit going from fpu to sse mode and back, as long as your data is in the correct format. ffts are an ideal candidate for sse btw - intel has sample fft code on their site i believe.
there's a small hit for using mmx - the mmx registers are aliased with the fpu registers, so when you switch between mmx and fpu you have to flush the register contents - this is done with emms. it also means you can't mix mmx and fp instructions. however sse can be mixed with both freely.

in terms of speedup it can be dramatic - for instance an sse multiply takes about 1/4 of the time to execute that a fp multiply does, and the sse version multiplies 4 numbers at once to boot!
as a side note - floating point is faster than integers on p3 class and later cpus if you're doing any significant multiplication or division. adding and subtracting is faster on integers though.

btw, when you set the headroom to 0, did you do that for just mplayer, or the mod player too?

[jmarshall]

thanks butcher for the info.

will have a look at seeing what sort of speedups i can make. am quite interested in this as i often write code for applications at work that could be converted to sse based stuff quickly.

will have a look at the intel fft stuff if i have a chance as well.

the setmi*****headroom() call was only made in ac97directsound, so only for mplayer and cddaplayer at this stage.

snyper:

the slow down is due to the amount of cpu we are using for the upsampling. hopefully sse to the rescue here!

in debug mode, things are far worse :)