Pure Player

Hi,npetralias

How about compatibility this player with ASIO ?

My setup:
Notebook OS Windows XP SP3 - Fidelizer 1.6(Audiophile Mode) USB ASIO driver ploytec 2.8.40 - USB/SPDIF Converter Teralink-X2 (A&B SYSTEMS Upgrade Version ) wit Teralink X2 Power Supply X2PSU - Benchmark DAC1

Using player's:
cPlay 2.0b36 SSSE3;
Foobar2000 v0.8.3 (recommended Empericial Audio).
 
Hi, Npetralias,

I am not sure you notice a bug with version 2.7.1, it deals with loading and playing a whole CD. I execute this, it loads only 2 tracks and plays them repeatedly. I tried only once and did not try it again.

I got around by loading the tracks and play each one, this works ok, like you say it takes longer to play in between tracks, and also some distortion at the start of each track.
 
If you decode a flac to wav manually and play it using a decent command line memory player in high process priority the result will be the same. These 2 observations made me to start developing PurePlayer, there are no secrets or magic. Obviously the problem is related with the OS (Windows) implementation (threads, memory allocation, software buffers etc).

What is the difference between manually decoding a flac to wav and a player application applying the exact same decoding algorithm ?

Most players i use run in high priority anyways.
 
What is the difference between manually decoding a flac to wav and a player application applying the exact same decoding algorithm ?

Most players i use run in high priority anyways.

The load during realtime decoding of flacs is causing extra load. Not much, but sufficient to cause more physical distortions.
Somehow this is causing more jitter/timing variations resp. extra common-mode noise.

It's important where the decoding takes place though.

On a Squeezebox system it is sufficient to let the server decode the flacs and to stream PCM data to the client which feeds the DAC. Decoding processes are very well isolated
due to the server/client structure.

On PC based transports with local playback you decode the flac prior to playback.

Even if phofman won't believe it an never did, I reported these effects years ago.


Nowadays all kind of so called audiophile players, decode flacs prior to playback and do ramplayback to name a 2nd very important feature.

If audio interfaces would be able to cope with those little distortions we wouldn't have that discussion and all these players as well as my SB modifications would be obsolete. Unfortunately I'm not aware of any device which can cope with those distortions. That'll
make every PC based transport sound different on the very same DAC device.

Enjoy.

Cheers
 
The load during realtime decoding of flacs is causing extra load. Not much, but sufficient to cause more physical distortions.
Somehow this is causing more jitter/timing variations resp. extra common-mode noise.
...
Even if phofman won't believe it an never did, I reported these effects years ago.

Well, you argue that the extra CPU load induced by FLAC decoding will cause "physical distortions", causing deterioration of the sound quality, while at the same time you argue the extra CPU load induced by your recommended playback buffer minimization to reduce playback latency (more frequent IRQ servicing, more frequent data transfers, more frequent player wakeups), and the extra CPU load induced by inserting additional item into your "highly recommended" playback pipeline - ecasound, yield improvement of the sound quality.

And these obviously contradicting arguments are based on what you and reportedly a few others have heard. No proper statistically objective blind listening tests were conducted, at least not a single one was reported. In a professional community this kind of subjective statement would not ever be taken seriously. But I understand unsupported claims are good enough for some audiophiles who just live to believe...
 
Last edited:
I posted in this thread before and claimed that i could not distinguish pureplayer from foobar. However, a problem i encounter these days with Windows OS made me think again about PC playback and i will post my problem here in order to find a solution and also to better understand what is happening with audio under Windows

My setup is the following one :

M-Audio Delta 192 PCI sound card
3.5 meter coaxial cable running from sound card to DAC.
DIY DAC based on SRC4382 and PCM1792A

No matter what player i use ( or sound generating program, could be Firefox for example ) it sometimes happens that the music is distorted beyond clearly distinguishing the original sound.
To better describe the behavior imagine a playlist loaded in foobar and clicking next button... everything works as supposed to until one track will be distorted in the way described above... after clicking next again or replaying the same track, the playback will resume under normal conditions. This only happens i would say once at a hundred tracks or so and i believe it to be a software problem that appears only under Windows XP. Somehow the data sent to the sound card is scrambled, or maybe the soundcard scrambles the data.

Now, i do not want to post offtopic here but this makes me believe that there are more important factors at play that affect the audio data than the software player, CPU load etc.

How can i further investigate this problem ?
My intuition tells me that this could be caused by a bad timing somewhere on the way. But if so, pureplayer or any player still do not resolve timing problems.
Joking a bit : Or maybe these are exactly the "physical distortions" discussed before.
 
M-Audio Delta 192 PCI sound card

The card is based on Envy24 which does no DSP, no data transformations.

No matter what player i use ( or sound generating program, could be Firefox for example ) it sometimes happens that the music is distorted beyond clearly distinguishing the original sound.

This sounds like overruns issue - the soundcard was starved of fresh data. It can happen when your system gets hogged by another driver.

Did you try increasing the DMA buffer size on the soundcard's control panel?

The weird thing is that you can fix it by skipping to next track. But who knows what the windows driver does when opening/closing the soundcard.

Perhaps we should move this discussion to a new thread :)
 
Last edited:
The card is based on Envy24 which does no DSP, no data transformations.
I know there is no DSP but there is the option to re-sample the data.

This sounds like overruns issue - the soundcard was starved of fresh data. It can happen when your system gets hogged by another driver.

Did you try increasing the DMA buffer size on the soundcard's control panel?

The weird thing is that you can fix it by skipping to next track. But who knows what the windows driver does.

Perhaps we should move this discussion to a new thread :)
when opening/closing the soundcard.

I tried to modify the buffer size with no effect. The only effect i can clearly tell is when playing 24bit / 192Khz with a small buffer there are many drop-outs present related of course to CPU load.
 
The card itself cannot do any resampling. I did find such option in the description of the control panel either http://www.m-audio.com/images/global/manuals/AP192_UG_EN1.pdf . What option do you mean?
I have the updated drivers with the new control panel.
Under hardware settings you can select codec sample rate. Under normal operation there is no re-sampling being done, but if you manually select a different sample rate, the card will re-sample to the desired rate.
 
I have the updated drivers with the new control panel.
Under hardware settings you can select codec sample rate. Under normal operation there is no re-sampling being done, but if you manually select a different sample rate, the card will re-sample to the desired rate.

Are you really sure the resampling occurs? The card itself cannot resample. It could be the driver, but I would be surprised if the windows driver developer implemented the resampling functionality. It is not generally the case for Envy24-based cards, at least those I have seen. Of course resampling can occur in the upper layers of windows audio stack, but I assume you are using ASIO or equivalent interfaces which should not resample on their own.

The sample rate switch on the control panel is just for switching the card clock. I do not know the latest drivers, but the functionality described in the user manual does not resample, it is just default samplerate the card runs on when no music is being output. It should switch automatically to the samplerate of the track, unless the "lock the rate" option is checked. In such case it should throw error and refuse playback since the only other way to satisfy this combination would be to resample. Which is what I would guess does not happen.
 
Are you really sure the resampling occurs? The card itself cannot resample. It could be the driver, but I would be surprised if the windows driver developer implemented the resampling functionality. It is not generally the case for Envy24-based cards, at least those I have seen. Of course resampling can occur in the upper layers of windows audio stack, but I assume you are using ASIO or equivalent interfaces which should not resample on their own.

The sample rate switch on the control panel is just for switching the card clock. I do not know the latest drivers, but the functionality described in the user manual does not resample, it is just default samplerate the card runs on when no music is being output. It should switch automatically to the samplerate of the track, unless the "lock the rate" option is checked. In such case it should throw error and refuse playback since the only other way to satisfy this combination would be to resample. Which is what I would guess does not happen.

No, the resampling does not occur under normal operation. However as you also said and also as written in the operating instructions the card is able to re-sample during playback. I just noted that re-sampling is possible ( and with the new drivers i am able to down-sample during music playback right down to 16Khz ) and do not think this has anything to do with the problem discussed. It would be very interesting to find out what is really happening and how the card is initialized for playback.
 
No, the resampling does not occur under normal operation. However as you also said and also as written in the operating instructions the card is able to re-sample during playback. I just noted that re-sampling is possible ( and with the new drivers i am able to down-sample during music playback right down to 16Khz )

I said the card can change samplerate - the frequency of its clock, the speed at which it operates. That is what could be written in the operating instructions. Is that what you call resampling?

I am afraid there are no decent debugging facilities for this soundcard in windows. If you experienced this problem in linux, we would have numerous powerful tools available, such as the capability to tap the stream at any point between the playback application and the actual driver, listing of immediate status of all Envy and codec registers, detailed statistics of eventual underruns, and lastly the source code of the driver, allowing us to easily make any modifications we would deem useful (e.g. printing debug messages at any place of the driver source code). But your OS does not provide you with such luxury.

At least you could inspect your kernel drivers latency with the latency checker and try to find any correlation with your problem.