[MPlayer-dev-eng] [PATCH] fix for -srate bug

[Ed Wildgoose]

>you insist on quality, yet you're not using overlay?!?
>i hope you know that all of the non-overlay vo drivers do not sync to
>vblank, so you'll get horrible tearing. that's a much worse offense
>than slight distortion in resampling, in fact it makes things
>unwatchable...
>  
>

I have no idea what output driver I am using.  I think I forced "noxv" 
in order to get the software scaler to work, and "sws=10".  The monitor 
refresh rate is exactly 50 Hz

I have to be honest, I can't see any tearing on either 50Hz or 60Hz 
stuff.  I do see some tiny jitter when playing 60Hz video (obviously), 
but I haven't had time to work through the config to get it to auto sync 
correctly.  It tends (by default if I let it) to pick unusual 
resolutions when a near perfect resolution is available.  It may be 
related to my nvidia card only supporting things like 720x756 and not 
768x576, despite the output tv being 16:9 resolution...  Something to 
look forward to anyway...

Anyway, upshot is that with my Jack patches (and the alsa patches I 
submitted a long while back), the video output is actually very smooth....


>>The CPU requirements seem unusually low in your case, but perhaps this 
>>is because of the integer optimisation?  For comparison, Brutefir 
>>    
>>
>
>well i also said my case is 2-channel only.
>  
>

Can you please tell me how to setup the same setup as you have?  I would 
like to test it?


>if you use really long filters then it will be slow, _and_ i expect
>you'll generate (pre- and post-) echo artifacts. this is just based on
>very naive mathematical intuition, so it's possible that more advanced
>filters have some workaround.
>  
>

Opinion seems to be that post "echo" is hard to hear at high frequencies 
(unlike pre-echo).  Also phase distortion is hard to hear at 20Khz.  So 
the upshot is that a min phase filter would seem to be ideal, and there 
is quite a lot of research on brickwall filtering out there already, so 
basically we are just doing the same thing that a CD player already does 
all the time (so if you don't think that cd output has horrendous 
pre/post echo then we should be fine).


>>OK, well steady on there.  I didn't write libsamplerate, and it's only 
>>popular with me because I have tested it's audio performance and found 
>>it indistinguishable from the original.  It's CPU requirements seemed 
>>similar to those of the mplayer resampler that I was trying.
>>    
>>
>
>well the resampler in mplayer is totally unoptimized... but i never
>recall having any high cpu usage when using it. i just force linint
>instead because of some extreme borderline cases where i need every
>cycle i can get.
>  
>

Sure, that's fair enough.  If you have low CPU then basically you can't 
do high quality resampling!  Seems fair enough really.  In any case, 
most people shouldn't need to be resampling - I guess the most common 
need would be playing CD audio out via some external decoder that only 
supports 48Khz..?  I think most people though can probably just output 
at the right rate?

In my case I need to pre-generate a huge bunch of filters and set them 
up at a single rate.  Also, Jack locks onto a single rate...

I'm still trying to understand your 1-2%cpu case.  If you mean that it's 
1-2% when doing linear interpolation then we are talking completely 
poles apart.  Yeah, if I use that on mplayer then it's negligable CPU 
load, but the problem is that the quality is horrendous and there is a 
large amount of "buzzing" and "ringing" on certain sounds.  I watched a 
film using that mode the other day and it drove me nuts by the end.  The 
high quality resampling code burns a ton of CPU (which I would expect it 
to), but the quality is loads better, but I *think* still audibly lower 
quality (I have only tested briefly you see)

So I just want to make sure that we are talking about the same thing, ie 
that you are doing polyphase filtering of two channels of audio in 1-2% 
on your machine?

Thanks

Ed W


>rich
>
>_______________________________________________
>MPlayer-dev-eng mailing list
>MPlayer-dev-eng at mplayerhq.hu
>http://mplayerhq.hu/mailman/listinfo/mplayer-dev-eng
>  
>