![]() ![]() Maybe some players can perform better, I do not know as I am not expert in Windows audio. Anyway, I still cannot say that what is seen here would always be the case. However, the only result that looked good in FFT was achieved with ASIO drivers. Spotify uses lossy audio codec causing some extra spectral deficiencies. Results vary depending on how the test tones are created, what is the sample rate of the file, the setting in Windows, etc. For these tests I used foobar2000 but also tried Windows Media Player and Spotify. I have tried these with one Windows 7 computer and one Windows 10 computer and with two different USB audio devices: miniStreamer and PCM2707C-based H-DAC. ConclusionĬomparing the first and the last FFT image tells a lot. H-DAC USB to analog output using ASIO4All driver, 0 dBFS tone. THD+N level of the signal below is -78 dBV which is quite bad number for a modern digital audio device. Obviously there is some resampling or whatever and the implementation is very poor, likely to achieve faster execution. And the results are even worse if sample rate is set to 44.1 kHz. You would imagine there was no resampling and output would be quite clean, if not bit-perfect. This signal is generated in foobar with 48 kHz sample rate and Windows sound device is set to 48 kHz / 16-bit output. Take a look at the spectrum below showing 997 Hz 0 dBFS signal played with foobar2000. This is purely a technical inspection but the differences are significant so I can easily imagine some golden ears can spot the difference. Its PCM2707C-circuit is capable of “only” 48 kHz / 16-bit audio so I was not expecting superb measurement results but was still amazed how bad they actually were. This post arose as a consequence of testing the USB-input of H-DAC. ASIO drivers or similar can improve audio output significantly by bypassing Windows resampling and other not-so-well implemented audio processing stages. ![]() By default, Windows audio quality can be technically inferior as has been shown in this measurement.Exactly, what I would like to being able to avoid for certain use cases. *Unless of course some resampling is bridged in between. Currently I am not even shure, wether the "-rates" setting is also applicable to recording. And that I wish to be able to configure with pipewire as well.ītw. So there certainly seem to exist some mechanisms to forcing an application into a specific sample rate. And so far, the detection of the samplerate required by jack has been working fine. To name jackd, that by design is running with a fixed samplerate, and the applcation cannot change this*. However, what I have been looking for is a way to tell pipewire not to resample, so if the application request a samplerate that is not available, because the stream is coming in with a different samplerate, to report an (unsupported) error to the application. And for most use cases that transparency is perfectly fine. If both do not match, pipewire will resample to satisfy the application. I'd rather suspect, the application makes a request for a given samplerate, and pipewire then brokers between what actually comes in (if it is a direct digital input where the AD converter sets the clock) or tries to set the samplerate accordingly (if it is an anlog input or some digital/digital converters). I am not entirely sure, that is the full story. What comes as the input is defined by the application starting the recording Thanks again, I will see, what I can do and get back with more information. Should have checked that earlier, but was fixed on the pw-top infos. Anyway, I guess, I need to sort this out first, even though I am not yet sure where to start.Īnalog to USB on the DrDAC works and as fas as I understand the manual, SPDIF (coax & optical) ->USB should work as well. Audacity confirms no level, but I never got along with that program, so that may just be me. However, for my principle problem: Actually looking at the pw-record file, it is empty, so somehow so signal arrives at all. Just opening it is enough, no need to change any settings. And after stopping pw-record pw-top only switches back to 44.1kHz as soon as I open the mixer (plasma-pa, does again not happen with pulsemixer, though). Pw-top shows an input of 44.1 kHz, however, when I then run pw-record without any arguments, it switches to the default 48kHz. As there are practically no USB->toslink Soundcards available (as in toslink -> USB, other way round is no problem). I am trying to feed an analog signal, converted by a RME ADI-2 ADC via toslink into an ESI DrDAC, which in turn should convert the toslink signal into USB. Indeed it seems, I have a different problem. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |