[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 setmixbinsheadroom() 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