Haha guys ... just wanted to vent a bit;
As I told elsewhere recently, I grabbed the situation of 0.9x-7 being nicely stable to start any larger project I wanted, with the downside that the other never gets finished because always something (like another larger project) comes in between.
Now, as you may have read, I finally found the culprit of devices like the Off-Ramp not wanting to work, that actually being devices needing 24 bits input. While I thought the solution would cover for the "HD Audio" devices being similar (laptops most often have them with 24 bit inputs only) I dove into the matter of an HD Audio Device allowing 16 bit input just the same, and ... found that it wouldn't do anything else than that (also see
Re: will not play hi-rez files ) no matter the "Off-Ramp solution".
Well, having the idea about such a culprit by now, it didn't take all that long to get that going as well, and by working on it for some 5 hours and just a 100 lines or so of coding, I think now all stupid strange device combinations are accepted ... err ... for initialization.
What if I tell you that the audio engine really playing the samples could comprise of maybe 30 lines of code, that covering for all the bit depth and sample rate combinations, when I had done it like it uses to be. Call that structured programming, whatever. However, and I told it before, to maintain the audio quality throughout, it couldn't be done by a "structured" means, and the audio engine (#3 only) which could have been covered in those 30 lines, now is over 18000 lines of C++ code.
Yesterday already I have been thinking on how to approach the integration of the "24 bit input only" devices, and actually couldn't come up with anything feaseable. And when I sat down this morning to make some start anyway and found the HD Audio Device to work different again, well, I made it to work for initializing it because that had to be done anyway, but now the problem got worse by a factor of ten.
All the combinations, them being over my head already, now will grow out of proportion, and the program will become unmanageable. Yes, that happens when programming is done in the not structured way.
In this case, think of, say, some 30 native combinations of bit depths and sample rates, which just will become 90 if all could be seen independently though "mixed" (hard to explain), but which is not independently because of the IMO stupid plain -I say- bug of WASAPI not being able to address this by one explicit means, but two in parallel which must be consistent.
If I could explain it I would, but it comes down to things in the area of devices needing 32 bits on their input while initializing of the device requires 24, versus devices needing 24 bits and initializing also requires 24, versus devices being 16 bits only but 24 bit files are allowed to be played just the same (by XX that is), versus 16 bit files which must be converted to 24 first because the input must be 24, versus files which just are 24 but need the 32 bits on the onput for those devices requiering that, versus 16 bit files which are converted to 32 because -so far- it was assumed that it wouldn't go otherwise, while now the 24 bit input devices won't accept 32 bit output, nor 16 bit output but 24 bit only, versus 16 bit files which you require to be upsampled them too ending up in 32 while in the cases concerned in can be 24 only, versus one crazy (hi Mani) who asked for 32 bit float files for input, while -never mind the DAC can do 192- in the cases concerned this has to be converted to 24 bit integer or otherwise 32 bit integer (so, I just forget about this one, sorry), versus something like a 352.8 file (DXD) which needs downconversion for those not owning 384 capable DACs, and which in the cases concerned has to be converted to 24 bits instead of the now common 32 or 16 depending on the DAC setting, versus the not even there yet -though now needed for the new filtering possibilities- upsampling from 88.2 or 96 to double that rate, versus that new filtering which is a pre-pre process ending up with 32 bit files in the first place now just passed through to the engine part concerd, but which have to be downrezzed to 24 again for something like the Off-Ramp while such a case won't let initilize the device (hey, 24 only is 24 only), versus ... I think I can go on and on, but mix in all the normal conversions everywhere (like using 24 real bits at 16 bit files and using the digital volume).
So you see, I was in a kind of trouble anyway, but this really does it.
It is not that the program won't be maintainable because of its redundancy and size (all what works, just works and needs no maintenance) but the structure needed can't be overseen anymore. This is similar to it needing 5 hours to initialize the device for all the combinations, but with the upside that's just new code and unrelated to conversions.
There are some more things I don't even know the solution for, which for example is about the DAC Test;
As we all know this is not in all cases reliable as it is now, which just is about the so far unrecognized combinations, them now being necessary. The point here is, you first need to set your DAC to what it is, before the output of the Test is reliable. Do that wrongly, but virtually include the new code, and you'll have static in some cases. The "some" is dangerous because you may be allright for weeks, until you at last play that setting you never did before, and only then it appears that you chose the wrong DAC setting afterall.
Take as example the HD Audio currently allowing for 16 bits only when it allows for 16 bits in the first place (see link I referred to), combine this with the now necessary means of initializing including the playing code, and find yourself ending up with static because something like an RME Fireface tells that it accepts 24 bits as well, while it really does not and static will be the result. And to keep in mind, this is just a matter of swicthing audio devices (like I have them all here now), and forget applying the DAC settings accordingly, and there you have it. How can I tell the real merits ? I don't think I can. What I can do though, is providing you with a saved setting per device, so that can be restored at switching, which by itself may contain a bug, and urges for another small project anyway.
Might someone run into Bill Gates, tell him I don't like him much. Not today.
No, today I also don't like Elias Gwinn and Steve Nugent.
Or maybe I should blame USB audio on this matter.
Those who created the HD Audio Device, same to you !
Why is this no problem in non-WASAPI players ? because the OS takes care of all the other situations, except for ASIO. I guess there the problem will be the same, although I imagine a truck load of programmers dealing with the situation, which still is a 1000 times less bad because it is setup in a structured fashion.
Allright, had to vent. Done that now.
Peter
