48kHz direct digital output

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

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

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.

hear hear!

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

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?

@ 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

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?

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

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.

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.