| Re: ASIO DRIVER current status ? [message #108439 is a reply to message #108437] |
Sun, 26 October 2014 00:15   |
Kim W.
Messages: 189
Registered: January 2010
Location: Australia
|
Senior Member |
|
|
Nice work, Mike.
This sounds very promising, even though I'd be happy with just 16 bit.
I still love the Paris software, but it is very picky with some plugins, which can crash Paris. I am using WIN7 64bit, but these issues existed with XP 32bit as well.
Looking forward to trying the ASIO driver with my next favourite DAW, Samplitude. (Native inserts on submixes would be joyous!!)
I'd stick with the Paris software if I could even do something as simple as strapping an external compressor, or even better a native plugin, on one EDS submix, (not just the global mix..)but alas this is a hard wired limitation.
Keep us posted.
Kim
|
|
|
|
|
|
| Re: ASIO DRIVER current status ? [message #108442 is a reply to message #108438] |
Tue, 28 October 2014 07:46 |
mikeaudet
Messages: 476
Registered: February 2009
Location: Canada
|
Senior Member |
|
|
Hi All,
I just wanted to give an update. Getting the PARIS hardware to work with Pro Tools 10 reliably has been really challenging, and I'm still working on it.
I had to re-write the buffering engine to work at all because even though the ASIO spec has a mechanism for asking the driver what it's buffer sizes are, Pro Tools only allows 64/128/256/512 etc. The PARIS hardware requires buffer sizes that are a multiple of 10 for 24 bit transfers. So, I had to change things quite a bit to get it working.
The next two hurdles were because of bugs I created. Those bugs are my fault, but Pro Tools closes as soon as it detects a debugger attaching to its process. This is probably done to make it harder to crack the PACE copy protection. In my case, it just makes it harder for me to fix things.
I had a bug that didn't manifest in other hosts because they always initialized the buffers in the order the driver presented them to the app. Pro Tools changes the order, and that reveled a mistake I had made. It lead to not being able to record audio in Pro Tools. It's fixed.
The second bug I've been trying to track down is a crash that sometimes happens when the buffer size is changed. It seems to happen more when the buffers are at 128 samples, but I've seen it at higher buffer sizes, too. Because I can't use a debugger and the problem hasn't manifested in other apps, this has been really, really hard to track down. I've literally spent days and days coming up with new theories and trying to prove or disprove them. I think I've finally found the problem, and I hope to have it fixed in about a week.
As long as the buffer sizes are not changed, Pro Tools works perfectly right now. So, we're not too far away.
I'll post when I finally have this resolved.
I just wanted to let you guys know what is happening, and that I'm still working really hard on this.
I have to give an extra special thanks to the beta testers who have helped us get to this point. You guys rock!
All the best!
Mike
|
|
|
|
|
|
|
|
|
|
| Re: ASIO DRIVER current status ? [message #108464 is a reply to message #108462] |
Mon, 17 November 2014 08:54 |
mikeaudet
Messages: 476
Registered: February 2009
Location: Canada
|
Senior Member |
|
|
Thanks, Will!
I think I found the bug I've been chasing. I discovered last night that the top 8 bits of project time are filled in by a helper thread in the PSCL, while the other 24 bits are read directly off the card. I think what has been happening is that I schedule the buffers before this thread is running, so I'm setting some things based on 24 good bits and 8 bits of garbage. If I stop the ASIO driver, the PSCL keeps running, so the helper thread is already running on the second attempt, and this second try always works.
I'm going to have to rewrite a bunch of stuff in the PSCL, but I should have this fixed by the weekend.
The Pro Tools problem was caused by something called dynamic priority boost in Windows. It boosts a thread's priority if it was waiting on an I/O operation or is involved in mouse input to the main window. This was causing mundane threads to preempt my timing loop and causing under-runs. I turned it off, and things worked so much better. I'm pretty sure reaper turns this off itself, which is why everything worked so well under reaper before.
All the best!
Mike
|
|
|
|
|
|
|
|
|
|
| Re: ASIO DRIVER current status ? [message #108472 is a reply to message #108471] |
Sat, 22 November 2014 20:40 |
|
|
Don't know about FLStudio; the implementation of the ASIO driver should be excellent in Reaper since that was a big testing platform.
The completely separate Reaper PAF import functionality mentioned above, written for us by a Reaper contributor, is pretty much flawless within its limitations - because it depends on libsndfile, our main library for PAF's compatibility with the outside world, it's hampered by a lingering bug in libsndfile that makes gibberish out of 24-bit files generated by the Mac version of PARIS only, but all PC-PARIS generated PAFS should import as easily as you'd import a wav.
Strongly doubt there will be any ability to access PARIS effects, but it may be possible one day! Fully accessing I/O cards though, I would imagine yes, since that's always been a core goal.
As far as paying up - this is all entirely new work by Mike, and even if every existing PARIS user chucked in a far bigger chunk than what I suspect he'll ask it would pay him pennies per hour for this labour of love, so I will be first in line with my cash in hand asking why I can't pay more! 
"... being bitter is like swallowing poison and waiting for the other guy to die..." - anon
[Updated on: Sat, 22 November 2014 20:47] Report message to a moderator |
|
|
|
|
|
|
|
|
|
| Re: ASIO DRIVER current status ? [message #108476 is a reply to message #108475] |
Sun, 23 November 2014 06:29 |
mikeaudet
Messages: 476
Registered: February 2009
Location: Canada
|
Senior Member |
|
|
Hi Will,
I actually don't want to criticize ID over this. There is a lot of good stuff in their work that I'm learning from. I don't think Ensoniq really had the money they needed to get this done right. We can certainly criticize ID over how they have handled the PACE thing, though.
I think just had a breakthrough - maybe there is a way to get these immediate buffers time aligned. I just loaded up a pro tools session at 128 samples, and it played back properly the first time, twice in a row. I'll have to do a bunch more tests to make sure all is well, but it's worked twice, and those are the only times it's ever worked.
I still have to fix the locking, and I have to make changes to the helper thread in the PSCL. It runs every 256 samples and does a bunch of housekeeping. But it touches resources my timer thread needs, and there is no time for contention at 64 sample buffer sizes. I'll need to make changes so that a special version runs when the ASIO thread attaches,
This is going to be so cool!
All the best!
Mike
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: ASIO DRIVER current status ? [message #108486 is a reply to message #108485] |
Tue, 25 November 2014 17:41 |
mikeaudet
Messages: 476
Registered: February 2009
Location: Canada
|
Senior Member |
|
|
Hi justcosmic1,
I sure hope so I've got it solved. I don't have access to the microcode on the card, so I have to do a lot of guessing. It's possible that it was something else causing the glitches. I really hope I didn't malign whoever wrote that code or mislead you guys. But, the glitches seem to have aligned with when the top 8 bits changed, and there is all kinds of stuff in the PSCL that seems to imply others thought this was happening. I hope I got it right and its fixed. I've been running my 27 track Pro Tools session for the better part of tonight at 64 samples, and it's been solid. I'm not doing anything to interpolate the first 24 bits yet. I'm just reading them. I'm adding one to a counter that acts as the top 8 bits every time the first 24 bits end up significantly smaller than the last check, which means they have wrapped. That happens every 5 or 6 minutes. This works because it is very unlikely we will have no buffer switch for 6 minutes. So far, so good.
As for the c16s, that's a great question! I don't think I had been planning to support more than one, but I just took a look, and the PSCL does send the card number with the callback. So, I'll try to use that to support more than one. I have a few around here to test with, too. I just only use one to save desk space.
All the best!
Mike
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: ASIO DRIVER current status ? [message #109095 is a reply to message #109093] |
Thu, 03 March 2016 15:05 |
mikeaudet
Messages: 476
Registered: February 2009
Location: Canada
|
Senior Member |
|
|
Hi Will,
I was getting a fair bit of time in, and then we all got a cold, and I've had two sick kids at home to look after.
I've got the MEC control panel done. I just have to test the +4/-10 controls. It's hard to check that from remote desktop on a laptop in the car with PARIS running in the house.
Last week, I discovered a bug that I though was squashed wasn't. After finishing the MEC control panel, I started testing all sorts of settings, and With 24 streams of audio, I'm getting occasional audio distortion at 64 samples. By streams I mean 24 I/O ports in use transferring audio on my MEC and 442. I took a look through the voice engine code, and I think I've figured out why.
The core of the voice engine that runs on the EDS card is something called the "big loop." It runs every 64 samples. It does all the memory transfers, and then it checks for new streams to add.
I think the work involved in setting up the 24 streams is delaying the loop by a few samples, and it just carries on at that point, every 64 samples, but slightly late. That puts it slightly out of sync with the main loop in the asio driver.
That's my theory, anyway.
So, I've been working on it. I've almost finished a function to change the frequency of the IRQ firing on the cards. Since the big loop fires the IRQ every 4th loop through the big loop, the IRQ is always in sync with the big loop. I think I've figured out how to make it fire every 64 samples instead of every 256. I can then run the ASIO loop from that.
Other than that, I've just got to do a simple dialog for the 442, and make a couple of additions to the C16 code. There are a couple of knobs I haven't wired in, but it's pretty simple stuff.
That's the latest! I'll get it out the second it's done and working perfectly.
I'm starting to think ahead to the next steps. I'm thinking of attacking the PSCL to port it to 64 bits so we can get a 64 bit ASIO. I'm also thinking about the Mac a lot, given the state of Windows. Reworking the PSCL would make it easier to port it to a new OS.
All the best,
Mike
|
|
|
|
|
|
The PARIS Forums
Search
Help
Members
Register
Login
Home
