Title: More on switching sample rates in same playlist Post by: boleary on July 08, 2010, 03:08:23 pm Yesterday the following error occurred when XX went from a 16/44 file to a 24/96 file in the same playlist. (About half the time it works) I had to delete the config file to get things working again.
Title: Re: More on switching sample rates in same playlist Post by: PeterSt on July 08, 2010, 03:44:20 pm To me this looks like a clear case of running two (or more) instances of XXHighEnd.
Notice that this includes the situation : 1. Start XX 2. (Much) Later again Start XX, and Quit that. 3. Do something in the instance from 1 (plus Quit I'd say). I want to add to this that I would say it is just possible to run more instances (as long as only one plays), but a bit depending on unlucky combinations of things and when several threads "doing" things, this might go wrong. If I have had this 3 times, it is much. Never had to re-init the config structure though (not that I recall). I am not sure what to do with your thinking this is related to the format switching; I don't think the config stuff is even approached when XX is just running/playing; only at Start and Quit. All can be quite another matter if the config structure was corrupted in the first place. Then things are unpredictable (for me). All 'n all ... not sure what to do with this ! Peter Title: Re: More on switching sample rates in same playlist Post by: pedal on July 08, 2010, 09:58:00 pm I mix formats all the time.
Title: Re: More on switching sample rates in same playlist Post by: boleary on July 08, 2010, 11:57:59 pm Hey Pedal, what kind of issues are you having?
Title: Re: More on switching sample rates in same playlist Post by: PeterSt on July 09, 2010, 05:13:28 am I would have said it the same, but I guess that is dutch. :) Maybe Pedal should have said : Never had a problem so far.
Title: Re: More on switching sample rates in same playlist Post by: boleary on July 09, 2010, 01:58:23 pm For a minute I thought I might not be the only one......
Anyway, attached are some log files generated by playing 16/44 then 24/96. When the 24/96 started it played for about 20 seconds and then "Too Many Buffer Errors." Just thought I'd share....... :) Title: Re: More on switching sample rates in same playlist Post by: PeterSt on July 09, 2010, 03:10:58 pm Yes, always do (share) ... in the end it may lead to something ...
It looks like you have no Wallpaper stuff set here, so that is not interfering. But what is then ? Also, if I see it right, the 44.1 was doubled, and the 96 stayed as it is (Fx button should have been Active). Now, long shot : While your DAC switched from 88.2 to 96 it does this not at the time it is ordered for, but later, when the buffer is empty (you know, that buffer of which I suspect it is loooong). By itself this is good, or otherwise the speed would change when the 44.1 is still playing. However, looking at the asynchronous operation of the HiFace, at a certain moment in time it is ordered to hop over from 88.2 to 96 just the same, but the HiFace does that not on the same moment as your DAC does. Btw, keep in mind : the buffer errors come from the HiFace, not from the DAC which I can't see with the HiFace in front of it. Now, the HiFace will be drawing a "buffer amount" of bytes from the PC at 96, while the DAC demands them at 88.2 for the length of its buffer. This is not a synchronous operation, because the DAC will suck at the HiFace in a real time fashion (byte by byte), while the HiFace will demand bulk loads of data from the PC. But, asnynchronously or not, the buffer of the HiFace will get fuller and fuller because it doesn't empty (at 88.2) as fast as that it is filled (which is at 96 already). If I am right on this (your DAC to be blamed or not) this is a flaw of the asynchronous operation of the HiFace. But, maybe it is an inherent flaw, meaning the logic for the solution can't be there. Something like : the speed of emptying the buffer can only be determined by the clock from your DAC, while the speed of filling it is determined by the speed of the clock from the HiFace. From this follows that the clock in the HiFace must be a slave of the clock in the DAC, and ... no ... it won't be made like that, because it wil l have been made the other way around : the clock in the DAC must slave the clock in the HiFace; Now we are back to square one, because if the DAC only switches when its buffer is empty (good !), it -well- doesn't do that as long as it is not empty and in the mean time during the time it takes to play empty the buffer, you get a buffer overrun in the HiFace. The story is a (too) long shot, because your DAC shouldn't have a buffer to begin with. But be careful, I estimate MSB at least as smart as myself (:fishy:) and so they could have been smart a long time ago already. Assuming your DAC is still the MSB of course. Anyway, what looks rather clear to me is that the output rate of the HiFace doesn't meet the input rate, in this situation. Only then it can happen that suddenly buffer errors appear after a few seconds, while none being there earlier. You could ask this to Marco with only one sentence : Can you imagine the output bytes being at another rate than the (net) input bytes over a certain amount of time (a few seconds), while this same few seconds ago the sample rate changed from 88.2 to 96; with this imagine the response of the DAC behind it. Creative P. Title: Re: More on switching sample rates in same playlist Post by: boleary on July 09, 2010, 04:56:45 pm Thanks Peter. I'll email Marco and see what he says. Really appreciate your time in looking at this.
Title: Re: More on switching sample rates in same playlist Post by: boleary on September 19, 2010, 02:12:11 pm Well I guess i's the Dac, cause I continue with this problem with Windows 7 and a desktop. About half the time it works and about half the time I get "too many buffer errors". What is different is that with the laptop, if I then tried to continue playing music, click play on the next track in the list, I would get the dreaded (for me) "Device allocated but cannot play" error, which could only be "fixed" by rebooting. Now I can play the next track without having to reboot.
|