|
Audio Asylum Thread Printer Get a view of an entire thread on one page |
For Sale Ads |
129.33.19.254
Decided to have a look at the source code of the ASIO plugin I'm using, to see how the setting "Buffer Size" is actually used, to get the size of the buffer (in samples). On UI, the setting is exposed as a value from 0 to 63.
Here's what I discovered in the code:
ASIOGetBufferSize(&MinSize, &MaxSize, &_PreferredSize, &Granularity);
PreferredSize = _PreferredSize;
BuffPreferredSize = PreferredSize * BUFFER_SIZE * (cfg_buffer_size + 1);
First line is an ASIO SDK call to the hardware driver, populating values for Min, Max, and Preferred buffer sizes. Third line calculates the size of the buffer, where:
- PreferredSize is returned by the driver;
- BUFFER_SIZE is a constant, which is set by developer to 4;
- cfg_buffer_size is the config value set in UI, in my case 0.
So, if let's say PreferredSize=512 (I've no idea what it is in reality, and would have to run the code in debug mode on a machine with W4S XMOS driver installed), then actual buffer size in samples is
512*4*1 = 2048
When I feel like it next time, the obvious things to try are:
- Use MinSize instead of PreferredSize;
- Set BUFFER_SIZE constant to 2 or 1 - not sure how arbitrary is the value 4.
Follow Ups:
the problem with asio isn't the way the buffers are calculated it's the fact that there is a buffer for left and one for right so it's automatically doubling the required instructions to pass the data through the cpu, i think that's what gives it it's characteristic digital edge. Kernel streaming is best, wasapi event close behind. Have a listen to the latest mqn to hear what minimalist players can do.
The problem with programmers is they are given a spec and in a bits are bits world deliver solutions that meet that spec.
A pc doesn't need to be real time, it just needs to be good enough to fool the human ear to the satisfaction of the listener, a large part of the issue is the player software and the fact that the data needs to pass through the cpu.
As Tony L has said before, the data shouldn't be passed through the cpu at all, but few people are persuing that goal.
http://mqnplayer.blogspot.co.uk/
... you're wrong.
If you hear "characteristic digital edge" with ASIO - that means you haven't heard it properly implemented.
WASAPI is a no-go from the start, considering that it requires several Windows services, exceptionally harmful to the sound quality, to be running.
and yet people say my MQn player (wasapi) is the best thing they've heard > Jplay etc, wonder what I'm doing wrong. Don't know why you have a problem with me saying try my player to hear a minimalist player, I thought you were interested in the way code affects the SQ. I can't see anything in what I've said that would cause you to think I'm expressing a high opinion of my software.
http://mqnplayer.blogspot.co.uk/
Edits: 04/18/14
I don't find ASIO having a digital edge when buffers are set right and even KS has a digital edge if set too low.
I personally avoid ASIO for PCM but rather like the Foo ASIO DoP setup which handles DSD rather well.
Players are the creation of compromises made by the programmers. What they do is difficult to suss out as there are no published 'models', just claims. The CICS players sound second rate to me (rather hifi) despite the accolades.
1. The resulting size of the buffer is in BYTES, not samples;
2. Constant=4 apparently is for bytes per each sample, 2 per channel.
This IS the issue with consumer and audio software, with no clearly defined and validated drivers or settings for 'best' replay quality.
This I ascribe to ignorance, laziness or arrogance by some programmers, and ignorance of consumers.
If scientific software is written like this, then the world would have had many mishaps.
Even given proprietary hardware systems this kind of configuration is often required to achieve best performance. It's rarely the kind of thing where the jumper settings and software configurations don't rey on the physical attributes and/or the performance attributes of the attached components/pieces. In fact from one piece of identical hardware to the next we've had build in configuration data factors in order to guarantee performance. For systems this stuff can be done during the manufacturing process - but for people putting systems together on their own they need to understand and do it themselves.
Give me rhythm or give me death!
My experience in this forum has clearly shown me that there is FAR more ignorance about computer-based audio on the side of the users (proven on a daily basis, it seems). :-)
... of anything related to computer audio.
As such, it's hard to disagree with your assertion - probably first time for me.
yes, 'cause they are kept in the dark.
If you are well trained in programming, you define what you are doing at every step. The readmes in audio software is either non existent or a joke.
Well, that's certainly true. But, generally, software companies don't reveal the technical details of a program to its users (e.g. when was the last time Microsoft gave a detailed account of the way Excel works, under the hood?), because information like that is, generally, not particularly useful to software users. The problem I'm referring to is the peculiar manner in which audio software (and hardware) users ascribe all kinds of bizarre characteristics to an implementation that is generally fairly straightforward (from the programmer's perspective).
I think the best example of this was audioengineer's (or whatever his name is/was...the guy from Empirical Audio) analysis of the various versions of Otachan's Foobar2000 resampler plug-in...he described tremendous differences in the way they sounded, which turned out to be rather amusing when I managed to dig up Otachan's code changelists which often consisted of just minor UI changes (i.e. move around a button on a dialog box).
... and I assure you they make HUGE difference to the sound quality, especially if you know which ones to tweak - there's something else.
From what can be found on the web, it appears that Otachan is/was pretty much "bits is bits" kind of guy, and did not specifically test his code for sound quality. Even without looking at compiler settings, the mere fact that his code in 2006 was compiled with MS compiler tells those who understand everything they need to know.
Imagine buying a car whose manufacturer says this!!!
"Imagine buying a car whose manufacturer says this!!!"
I don't follow you. What do you have in mind that they might say?
Tony Lauck
"Diversity is the law of nature; no two entities in this universe are uniform." - P.R. Sarkar
"I think the best example of this was audioengineer's (or whatever his name is/was...the guy from Empirical Audio) analysis of the various versions of Otachan's Foobar2000 resampler plug-in...he described tremendous differences in the way they sounded, which turned out to be rather amusing when I managed to dig up Otachan's code changelists which often consisted of just minor UI changes (i.e. move around a button on a dialog box)."
Your comments about these versions would have more substance if you had been able to look at the machine code generated by the compiler. The same source code will produce different object code with a different version of the compiler or different compiler settings. After going that far, it would also be necessary to verify the relative location of the object code. It could be that changing the relative location of various code would affect the cache miss rates and that could have a huge impact on system performance. This effect would be harder to measure and might require specialized equipment or software, but it would be necessary for any thorough analysis of the situation.
In short, you have provided no evidence that the two versions should sound the same. This should be contrasted with the evidence several people provided by using their ears.
Tony Lauck
"Diversity is the law of nature; no two entities in this universe are uniform." - P.R. Sarkar
He heard it and that justifies what he said.
On the contrary, you have provided no basis for your assertion other than that he should spend perhaps a couple of days looking at computer codes. This is not 'on the side of users' or anyone else.
There is some confusion. I believe we are in agreement as to the substance, namely how the different versions compare.
I believe the different versions sound different. I believe this on the basis of the listening tests that have been reported. Of course it could be that these were mistaken and if there were evidence that the two versions had identical content (object code) then I would have withheld my opinion, as there could be other explanations for why the different versions sounded different. However, Scrith's "evidence" (nearly identical source code) is quite incomplete for the reasons I explained. If he wants to look at details of the object code and how it is laid out in memory he is free to do so, and he might learn something. But until he does, I will pay no attention to Scrith's arguments. I will go with the listening reports, which are probably correct.
What this case illustrates is just how hard it is to understand computer audio. This supports my argument that we will never get consistently good sound by tweaking software. This approach is poor systems engineering, albeit expedient in individual cases. It has been well known since I worked with hybrid (analog plus digital) computers back in 1961 that one needs to have a strict barrier between the digital and the analog worlds for best results. This is primarily a matter of hardware engineering, not software engineering.
Tony Lauck
"Diversity is the law of nature; no two entities in this universe are uniform." - P.R. Sarkar
"This supports my argument that we will never get consistently good sound by tweaking software. This approach is poor systems engineering, albeit expedient in individual cases."
Just curious, what actually is your definition of tweaking?
"Just curious, what actually is your definition of tweaking?"
Tweaking is making changes on a purely experimental basis without any substantive underlying theory. In other words, trial and error. It may involve listening, measurement or some combination thereof.
This is how I started. My uncle had a Dynaco mono block tube amplifier and it didn't sound good. We got a bunch to test equipment and noticed that the square wave response was poor. We then changed various components in the feedback path for ones with different values and observed what we saw on the scope. Eventually by trial and error we thought we had fixed the amplifier as the square wave response was now good and the distortion and power measurements were unchanged. We hooked it up to the speaker and before long we observed that the plates of the output tubes were now becoming brighter and brighter red. Fortunately, we didn't damage the tubes or burn out the speaker. Back to the drawing boards and we tried again, this time after a little investigation of why were were getting oscillations. A proper engineering approach would have included an understanding of poles and zeros and other aspects of electrical engineering. My Uncle was an artist, textile designer, and former art professor. I was a 13 year old kid. Years later I understood what had happened.
Tony Lauck
"Diversity is the law of nature; no two entities in this universe are uniform." - P.R. Sarkar
"Tweaking is making changes on a purely experimental basis without any substantive underlying theory. In other words, trial and error. It may involve listening, measurement or some combination thereof."
Are you assuming one has no idea what they are doing?
Even the best designer, "tweak" their designs.
The best designers don't begin tweaking until they have reached the end of their technical understanding. The difference is that these people begin with a lot of technical understanding, something which is not so common in these quarters.
Tony Lauck
"Diversity is the law of nature; no two entities in this universe are uniform." - P.R. Sarkar
"The best designers don't begin tweaking until they have reached the end of their technical understanding. The difference is that these people begin with a lot of technical understanding, something which is not so common in these quarters."
Not everyone is clueless though. :)
Some of the most famous discoveries have happened by accident.
Since this is actually still a pretty new field, experimenting is not the worst thing either. It is still a hobby, and hopefully nobody will get injured from computer tweaking.
Consistency in audio is a function of the combination of too many variables. However, I do all my evaluation listening on the same PC hardware. If you do this, you can weed out software and OSs that don't sound particularly good.
Server 2012R2 with minimal function does sound quite a lot better than other MS OSs with W8.1 x64 following. You should try it with a small ssd in your pc.
Whether the programmer or end user does the tweeking the end results depend on their skills and understanding of the system on which the software is running.
The programmer can only guess what that will be - the end user on the other hand knows exactly what it is.
"Consistency in audio is a function of the combination of too many variables. "
As far as I can tell this has been pretty much an audio truth since long before PC's ever became a part of the system.
Give me rhythm or give me death!
"In short, you have provided no evidence that the two versions should sound the same. This should be contrasted with the evidence several people provided by using their ears."
The latest JPlay is available in two versions. The only change is compilers. They do sound different.
A compiler change (and a compiler settings change, even with the same compiler, for that matter) could certainly create a significant difference with time-sensitive code, or code that requires a lot of resource (memory or drive usage, for example). Moving around the location of a few buttons (which are probably stored via 2D coordinates in a data/resource file) is something else entirely, however.
Too bad so many seem to think they are worthy as teachers...
Give me rhythm or give me death!
You have incorrectly ascribed the problem. The problem isn't laziness or ignorance, it is the hyper-astronomical number of system configurations most of which can never be expected to work well, let alone be tested.
It will never be possible to take a general purpose computer system where hardware and software components are designed loosely for minimum cost and maximum flexibility and produce a high quality real-time system. Such a system has to be purpose built from scratch and must be designed and configured under strict hardware and software version control. This is not how PCs are designed, built, sold, configured and used. This is precisely why I have repeatedly said that until the rest of the audio system is made sufficiently immune to all noise or jitter coming from the computer there will never be a completely satisfactory solution to computer audio playback. If you don't like this situation and can't find a suitable DAC, reclockers, power line filters, etc... then you shouldn't be using a computer, you should be using a purpose built transport.
There have been many mishaps with scientific software. People have been killed. There are whole forums on the risks of using computers.
Tony Lauck
"Diversity is the law of nature; no two entities in this universe are uniform." - P.R. Sarkar
"then you shouldn't be using a computer, you should be using a purpose built transport."
Tony,
How do you define a purpose built transport? Would you consider the work by Chris at Computer Audiophile a purpose built transport?
regards
Bob
I do use purpose built transports but many here don't, including you. So why don't you put your theories to the test and post what you hear here.
"I do use purpose built transports but many here don't, including you. So why don't you put your theories to the test and post what you hear here."
I am guessing this was not intended for me... :)
follow the quote
I know but it came under my post so I received an email. I knew it. I hope we get some useful input. :)
of later XMOS driver packs other than the Thyscon 1.62 WILL not install in Server 2012 come what may, including W8 compatibility. Weird.
To follow up try Win 7 mode. or in core mode use Phil's install command. It is explained in the AO PDF.
"including W8 compatibility. Weird."
Are you trying Win 7 mode? Win 8 is essentially the same as Server 2012.
I don't follow Chris's work, so I can't comment on it.
Tony Lauck
"Diversity is the law of nature; no two entities in this universe are uniform." - P.R. Sarkar
The CAPs Servers. Very well though out. He has put allot of effort into designing a proper computer audio server.
"It will never be possible to take a general purpose computer system where hardware and software components are designed loosely for minimum cost and maximum flexibility and produce a high quality real-time system."
That is why anyone who knows what they are doing and serious does not do this.
"Such a system has to be purpose built from scratch and must be designed and configured under strict hardware and software version control."
Exactly what I, and many others are actually doing.
I have finally listened to Server2012R2 and this sounds subtlely different (for the better) than Server 2008R2, Somehow there is an increase in ambience and fluency plus good tonenality.
Howeevr, I have an issue with drivers. On XMOS, Thyscon 1.61 works and install as 64 bit. But XMOS 1.5 and 1.9 refuse to install at all. XMOS appears under Sound Controller, but the additional entry in Devices will not appear.
Have you come across this?
I am not using xmos. My DAC has the OEM hiface one interface. Many people are using xmos successfully though. Have you tried Windows 7 compatibility mode? If you still have a problem ask Phil on the JPlay or Computer Audio Forum. I am almost positive it should work.
regards
Bob
Give me rhythm or give me death!
Tony, I think you're making more sense than this forum can accommodate. ;-)
It's interesting that our resident armchair quarterback often claims ignorance, laziness, or arrogance on the part of programmers and "IT Guys" when he has demonstrated barely a superficial understanding of computer hardware, operating systems, or programming.
You're not learning this stuff too easily, are you?
Vacation until Tuesday April 22nd at 3pm EST.
Chris
Probably the most accurate and sensible post on this board all year. I agree completely.
There is no reason when writing a program not to define settings correctly, cheap or otherwse.
It is pure slopiness and arrogance in the sense that the user is unlikely to know.
"There is no reason when writing a program not to define settings correctly, cheap or otherwse.
It is pure slopiness and arrogance in the sense that the user is unlikely to know."
I'm not really sure what it is you are trying to say but this is how I take it -
There is no reason whatsoever not to program ideal settings as no matter how bad the results the user is unlikely to know.
Funny thing is - I mostly agree.
Give me rhythm or give me death!
some of these 'programmers' don't know what they are.
ideal setting should mean ideal performance. You'll never know what those settings are until you've assembled the system.
You might have a recommended or default settings as a starting point but the end user has to determine what is ideal.
Give me rhythm or give me death!
sounds different, you have no idea what the 'ideal' settings are.
Programming with your kind of stab at the truth is like wheel spinning, not knowing when it'll stop.
I give a 'hot-off-the-press' example. The Thyscon 1.61 usb2 audio driver works properly in Win Server 2012 and is in the 64 bit Program file. The updated versions of the same XMOS driver won't even install. Why? If the programming has been 'ideal' ' the drivers have been around for a long while'
Any setup or configuration prior to installation is a shot in the dark.
In this case the end users are audiophiles (not programmers) and they more than anyone else should understand how to figure out the ideal settings. If this is not the case they shouldn't be messing with these kinds of systems - but lo and behold they will and they'll revel in their wonderful results in spite on knowing not what they do.
Give me rhythm or give me death!
This is poppycock and if user settings are up to airplane pilots and train drivers, then god help the world.
This kind of reasoning demonstrates a lack of intellectual rigour and honesty on the part of some software providers; exactly what I have been saying.
Airplane controls are a part of a system that is meticulously calibrated to produce accurate results prior to the pilots ever seeing them.
A PC audio system is a conglomeration of parts that needs to be meticulously calibrated by the end user (or someone he pays to do it) in order to achieve accurate results.
Give me rhythm or give me death!
''A PC audio system is a conglomeration of parts that needs to be meticulously calibrated by the end user'' Poppycock!!!
You must be a shareholder in MS,HP or whatever. There is no logic in asserting this for any consumer product and is an assumption that lets companies make profit without responsibility.
Just about every professional electronic device under goes calibration on a regular basis. If you've ever worked in an engineering lab or hospital you will know and understand how important it is that these devices remain calibrated. Normally this calibration is done by individuals outside the group using the equipment or an outside company altogether.
And all of this after a system has been built, configured and calibrated and passed production testing.
And here you are claiming one should be able to assemble a system and get "ideal" results without calibration?
You're wrong!
Give me rhythm or give me death!
instead of posting unrelated points.
I am a professional engineer and you are talking way over your field of knowledge.
Period.My points are simple and exactly on point. You just don't get it - it's poppycock you saide.
You might be somekind of tech school product or an actually engineer with 0 experience in product development and manufacturing.
Give me rhythm or give me death!
Edits: 04/16/14 04/16/14
Post a Followup:
FAQ |
Post a Message! |
Forgot Password? |
|
||||||||||||||
|
This post is made possible by the generous support of people like you and our sponsors: