peufeu said:Anyway I still believe you'd be better off with slaving the PC to the DAC and remove the problem
This is of course the major problem with the way they fudged USB audio to work.
Somehow I doubt you actually have a 1 sample buffer, with an scheduler period of 0.5ms you've got 24 stereo samples being played out between each scheduler interrupt.
BlackCatSound said:
This is of course the major problem with the way they fudged USB audio to work.
Somehow I doubt you actually have a 1 sample buffer, with an scheduler period of 0.5ms you've got 24 stereo samples being played out between each scheduler interrupt.
One sample is that what I configured with ALSA. (Though I didn't measure it.
)I am not sure if e.g. the USB-controller or the USB-snd-driver buffers extra samples.
The PCM2707 buffers 3 stereo samples on its own.
In case another IRQ pops in you'd be right. I'd run into an underrun. But that's
not happening. There is a slight chance that there is another big buffer sitting somewhere. (Or no other IRQs are bothering me since mainly everthing is switched
off in the system and the system remains untouched while playing back)
People without rt-scheduling won't make it below 32samples ALSA buffer.
One thing for sure. There are still plenty of dark holes in a PC envrironment messing around with the stream. My intention is still to get these under control as much as possible. But it takes hell lot of work and knowledge.
The next action would be then to analyse the usb-snd-driver to make sure nothing goes wrong there. First you need to understand the driver itself than you need in-depth knowledge of the USB controler and management asf. All these things are
little projects on its own. peufeu knows what I am talking about.
Cheers
\Klaus
Cheers
\Klaus
BlackCatSound said:
I am running an external 12Mhz Tent clock. If that's what you mean.
There is no I2S reclocking.
Perhaps I should mention that my "DDDAC" is heavily tweaked (parts, construction, cabling and battery!)
BTW: I was in contact with Con Kolivas. He pretty much supported the approach to go towards 5000Hz.
He mentioned , that above 5000Hz, you might encounter problems that processes just die. (I'll try it anyhow!)
Beside that he mentioned that the 1ms slices at 1000Hz are not
really 1ms all the time. They can be up to 2-3ms long.
By running higher freqencies I am lowering this non-linearity.
Cheers
\Klaus
hi Klaus,
Had a quick look at the Kovalis mailing list to follow the audio discussion you instigated there. Interesting that he revealed himself as an audiophile and sounds like the timer could be the key element to the ideal audio setup. Glad he said that sheduler choice may not be that important as some of the discussion over there between the developers was pretty fierce - the level of competiton between them will ensure continued true open source development, but looks like a lot of releases and subsequent recompiling to keep up.
seems like you've had a major breakthrough here.
Anyway I had a google for os timer and audio and one of the first hits was an interesting microsoft article http://www.microsoft.com/whdc/system/CEC/mm-timer.mspx
some useful comment on how developers use buffers to get round the usually insufficiently low frequency timer, and that these buffers are not an optimum solution. Again discussion is based around video and audio synchronisation, but the kovalis comments may suggest audio quality itself is also a parameter.
Had a quick look at the Kovalis mailing list to follow the audio discussion you instigated there. Interesting that he revealed himself as an audiophile and sounds like the timer could be the key element to the ideal audio setup. Glad he said that sheduler choice may not be that important as some of the discussion over there between the developers was pretty fierce - the level of competiton between them will ensure continued true open source development, but looks like a lot of releases and subsequent recompiling to keep up.
seems like you've had a major breakthrough here.
Anyway I had a google for os timer and audio and one of the first hits was an interesting microsoft article http://www.microsoft.com/whdc/system/CEC/mm-timer.mspx
some useful comment on how developers use buffers to get round the usually insufficiently low frequency timer, and that these buffers are not an optimum solution. Again discussion is based around video and audio synchronisation, but the kovalis comments may suggest audio quality itself is also a parameter.
rossco_50 said:
I'd say thats aimed more at the likes of games developers where you are syncing the video effects to the sound samples.
The audio we're dealing with here is constant and needs no syncing to video etc...
peufeu, the daft thing is there is no need to have a steerable clock in a PC sound device, its just a throwback to CD players. If they fitted good fixed clocks to soundcards you'd have far better results.
yeah the microsoft article is only concerned with syncing video and audio, as I also said in my post. was really posting it as it mentioned the relationship between buffers and the os timer. it may be that others understood that previously, but it helped clarify why soundcheck was playing with the timer with relation to his theories of bufferless audio, for me.
syncing through spdif does indeed seem to eliminate a lot of the problems associated with that interface. I think though that usb offers a more achieveable and cost effective solution, and take into account there are folk who have tried both systems and report that usb, albeit for reasons unknown, sounds better. This is the route I am going to take, and linux tinkering is more up my street than designing clock division and buffering circuits (unless there is a circuit you know of that can be easily adapted to suit any dac?)
syncing through spdif does indeed seem to eliminate a lot of the problems associated with that interface. I think though that usb offers a more achieveable and cost effective solution, and take into account there are folk who have tried both systems and report that usb, albeit for reasons unknown, sounds better. This is the route I am going to take, and linux tinkering is more up my street than designing clock division and buffering circuits (unless there is a circuit you know of that can be easily adapted to suit any dac?)
BlackCatSound said:
I think by making smaller slices you get a smaller error or better you get less non-linearity into the stream. The few interrupts, not belonging to the audio stream, are perhaps consuming much less then 1 ms processing time in general. That's why it works I guess.
The realtime kernel makes sure that you get at a nice of -19
or a priority of 98 most of the slices allocated to your stream.
So it doesn't matter if it is 9,6 samples per interrupt or anything else. The 1ms buffer at the 2707 most probably doesn't play a big role here either.
BTW. I don't know what kind protocol and overhead is coming with the sample within the PC, I doubt that it is just 16 bit per sample.
Beisde that the time slices doesn't seems to be constant. Even
thinking to choose a frequency which would 100% match the word length wouldn't work here.
Cheers
Klaus
John Biles said:
Hi, I was wondering if it would be possible to create a Puppy Linux according to soundchecks observations -with rt patched kernel, jack and the rest of the proposed software. I'm not a Linux guy and I don't know if there are any technical limitations of Puppy for this role, but if possible, this thing on a usb stick(or live cd) would make a lot of people try "Linux audio" + coupled with the good usb dac it would turn (almost) any comp into a hifi audio source.
Actually, if I wanted to use USB sound, here is what I would do :
- put a master clock in the DAC with short clock path, reclocking all DAC signals
- put a SPDIF encoder using this master clock, sending SPDIF encoded silence to the computer. This SPDIF encodes the master clock.
- send this SPDIF to the input of the USB device
- computer plays music to the device's SPDIF output
- DAC has SPDIF input and plays this SPDIF reclocked with the master clock
Now this will only work if the computer slaves itself to the incoming SPDIF clock. I do not know if this is possible with USB. It would be very interesting to find out.
- put a master clock in the DAC with short clock path, reclocking all DAC signals
- put a SPDIF encoder using this master clock, sending SPDIF encoded silence to the computer. This SPDIF encodes the master clock.
- send this SPDIF to the input of the USB device
- computer plays music to the device's SPDIF output
- DAC has SPDIF input and plays this SPDIF reclocked with the master clock
Now this will only work if the computer slaves itself to the incoming SPDIF clock. I do not know if this is possible with USB. It would be very interesting to find out.
anli said:
Many of the tweaks I recommended are not USB related.
I just verified them with a USB-DAC.
Most of the tweaks are affecting the stream before it hits a souncard and/or external interface like SPDIF.
Unfortunately, as it seems nobody (except some USB-DAC people) - not even peufeu or blackcatsound
- seem to try them.Just try it and report back.
I'd be happy to learn if all this here is really related to an USB-DAC only. I doubt it.
Cheers
Klaus
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.