From the ALC662 documentation here http://www.datasheetspdf.com/datasheet/ALC662.html is clear thas this codec has one 24.0 MhZ master clock and 48 KhZ sample rate support (sent in one sample and 96 KhZ in two samples etc), 44.1 KhZ is also supported natively but through ratio 147/160 and appropriate sequence of sample frames (they call it delivery cadence) - chapter 7.2.5. SImilar mechanism is found in some other realtek chips.
Questions:
1) what does the described mechanism to the sound? Is it still bitperfect play, or do Realtek chips actually resample somewhat?
2) if it is bitperfect, does the used technique have impact on sound ? (jitter etc).
3) Does it make quality sense on those chips to resample 44.1 KhZ to 48 KhZ e.g. by using SoX or SSRC when playing by FoobarR on the fly?
Thanks,
Jan
I assume you're talking about playback?
Resampling can't be bit perfect (since you are altering the samples) and analog-to-digital or digital-to-analog conversion can't be bit perfect either, since there are no bits in analog.
I really wouldn't worry about it. Resampling is almost always transparent (as long as you stay at or above 44.1kHz and 16-bits).
It's "nice" to avoid unnecessary resampling if you can, but there's usually no problem if your soundcard has to resample at playback time.
What if Realtek resampling at 44.1-48 KhZ is worse than Foobars SoX or SSRC ?
What if Realtek resampling at 44.1-48 KhZ is worse than Foobars SoX or SSRC ?
It probably is worse, in order to avoid delaying the sound too much (realtime SoX resampling introduces a bit of delay), but it's very unlikely to be audible.
Then, if realtek upsamples to 48 KhZ native rate, is maybe useful to resample through SoX and send to realtek 48 KhZ ....
Then, if realtek upsamples to 48 KhZ native rate, is maybe useful to resample through SoX and send to realtek 48 KhZ ....
Sure, but it's exceedingly unlikely that you will hear any difference.
You could use a 20khz tone in foobar to test. Usually if the device isn't resampling, you won't hear anything (or very little). If it is resampling, it'll become much louder away from the fixed sampling rate (usually 48khz).
I cannot hear 20 KhZ, my reliable hearing (yes/no saying) is at 16-17 KhZ max ...
So what, then, was all the fear about noise-shaped dither and unsolicited bumping of discussions with your dither of choice and a TOS8 violation?
I cannot hear 20 KhZ, my reliable hearing (yes/no saying) is at 16-17 KhZ max ...
Then it should be very easy for you to test for bad resampling, as you will hear nothing without it.
Then, if realtek upsamples to 48 KhZ native rate, is maybe useful to resample through SoX and send to realtek 48 KhZ ....
SoX is known to
measure as a good resampler, but it's NOT known to
sound better than any random-average resampler (in a proper-scientific blind listening test).
If it makes you
feel better, go ahead and use SoX. ;)
Or if you want to be
paranoid, get a DAC or interface that supports a variety sample rates. Then make sure your device's drivers support WASAPI exclusive mode, or get an application and interface that supports true ASIO.
paranoid
IOW, wank away.
Sigh.
Sorry for disturbing.
I am already using WASAPI exclusive, my realtek codecs support 44.1,48,96 KhZ, but 44.1 with the technique I described.
Using SoX seems to be good alternative to internal technique.
Using SoX seems to be good alternative to internal technique.
Based on what evidence?!?
Seriously, stop with the nonsense!
To the hearing, I do not play only for myself but also for others members of our home. So strictly deciding by "hear/cannot hear at my 16-17KhZ ears" is kind of pointless, and generally I would like to play at the good quality regardless of what can be "exactly" heard or not. When making photos also you dont make bad quality saying that people have old LCDs.
If it makes problems, I can stop with this thread and keep trying on my own ...
That would be a good idea.
Discussion closed.
I will be happy to re-open if someone can, in keeping with our terms of service, demonstrate an audible problem with the resampler in question.