hi all...
i added my first working version of a native asio support for win32 to the devel_0_37 branch (i hope, i'll be able to check in a working devel_0_38 tomorrow).. ... since i only had the possibility to test with my old maudio quattro i need some feedback from people with other audio devices ...
please test and let me know if it's working or not ...
cheers ... tim
Hi Tim, great stuff!!
Three things: 1) doesn't work with RME HDSP, since it wants sample type 0 and 1 (don't know why both) 2) There is very fast float to int conversion code on http://www.mega-nerd.com/FPcast/ 3) Is it really necessaty to have thread mutexes for the ring buffer?
all the best, Thomas
----- Original Message ----- From: "Tim Blechmann" TimBlechmann@gmx.net To: "Pd-Dev" pd-dev@iem.at Sent: Friday, November 05, 2004 12:22 AM Subject: [PD-dev] native asio support
hi all...
i added my first working version of a native asio support for win32 to the devel_0_37 branch (i hope, i'll be able to check in a working devel_0_38 tomorrow).. ... since i only had the possibility to test with my old maudio quattro i need some feedback from people with other audio devices ...
please test and let me know if it's working or not ...
cheers ... tim
-- mailto:TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk
After one look at this planet any visitor from outer space would say "I want to see the manager." William S. Burroughs
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
- doesn't work with RME HDSP, since it wants sample type 0 and 1
(don't know why both)
couldn't test it with mine, since my laptop is running on linux ... i'll fix that ... 0 is 16 bit, 1 is 24 bit, both big endian ...
- There is very fast float to int conversion code on
i'll have a look at that ...
- Is it really necessaty to have thread mutexes for the ring buffer?
i took this from the jack implementation ... i'm not really satisfied with it and test some other possibilities ... see it as quick and ugly workaround also, i hope, i can manage to run the dsp scheduler from the asio callback to reduce latency ... we would probably get rid of the callback, then ...
cheers ... tim
Hi all, i'd like to report that after some more fixes i am able to achieve a measured click-free analog latency of 10 ms with the RME Multiface. In former times i haven't been able to go below 25 ms.
cheers to Tim Blechmann! Thomas
However, two things that are yet unsolved: 1) the ASIO driver of my RME HDSP soundcard seems to be _very_ sensible to being closed properly... it seems like this doesn't always happen (at least when i use it). Only reboot helps then. 2) the new asio_native driver gets opened as soon as PD starts.... i don't know why because MMIO should be the default. In a hurry, i couldn't find the spot where ASIO is activated instead.
best greetings, Thomas
----- Original Message ----- From: "Thomas Grill" gr@grrrr.org To: "Tim Blechmann" TimBlechmann@gmx.net; "Pd-Dev" pd-dev@iem.at Sent: Saturday, November 06, 2004 10:36 PM Subject: Re: [PD-dev] native asio support
Hi all, i'd like to report that after some more fixes i am able to achieve a measured click-free analog latency of 10 ms with the RME Multiface. In former times i haven't been able to go below 25 ms.
cheers to Tim Blechmann! Thomas
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
- the ASIO driver of my RME HDSP soundcard seems to be _very_
sensible to being closed properly... it seems like this doesn't always happen (at least when i use it). Only reboot helps then.
i had a similar problem on my quattro (the only audio device working on my windoze machine) ... switching of or opening the asio configuration tool helped ... i'm not sure, what's the reason for this behaviour ... somehow the driver side gets stucked ... this also results in a crash while closing pd (iirc, i've seen similar behaviour on linux)
- the new asio_native driver gets opened as soon as PD starts.... i
don't know why because MMIO should be the default. In a hurry, i couldn't find the spot where ASIO is activated instead.
i can't reprocude it atm ... for me mmio is opened by default ...
i'll check that ...
cheers... tim
i'd like to report that after some more fixes i am able to achieve a measured click-free analog latency of 10 ms with the RME Multiface. In former times i haven't been able to go below 25 ms.
i'm curious, which buffer size you where using ...
also, the current implementation is based on a ringbuffer solution ... i hope i can reduce the latency for odd asio buffer sizes (like multiples of 441 on my quattro) ... i haven't been able to improve the algorithms, yet.
and i hope there is a way to get rid of the ringbuffer to run the scheduler from the asio callback (something similar could possibly be done for jack) ... atm, i have no idea, how to do something like that, since probably i'll have to rewrite the scheduler itself ... but it should be possible to do that ... with that it should be possible to acheive latencies of 2*64 samples ...
also, i doubt that the current implementations is working on osx due the reversed endianes ...
cheers ... tim
i'd like to report that after some more fixes i am able to achieve a measured click-free analog latency of 10 ms with the RME Multiface. In former times i haven't been able to go below 25 ms.
i'm curious, which buffer size you where using ...
i used 128 frames of hardware buffer.
also, i doubt that the current implementations is working on osx due the reversed endianes ...
sure, but it seems that ASIO isn't really used under MacOSX any more. The next step would be a native Coreaudio driver.
best greetings, Thomas
i'd like to report that after some more fixes i am able to achieve a measured click-free analog latency of 10 ms with the RME Multiface. In former times i haven't been able to go below 25 ms.
i'm curious, which buffer size you where using ...
i used 128 frames of hardware buffer.
i was thinking ... this is too much ...
128 * 2 (input and output) are 256 samples ... that is 5.8 ms at a sampling rate of 44100 ... what have you specified as latency inside pd?
still thinking about a way to run the scheduler from the dsp callback ... tim
128 * 2 (input and output) are 256 samples ... that is 5.8 ms at a sampling rate of 44100 ... what have you specified as latency inside pd?
i have the impression that this doesn't play a role any more, since it is dependent on the hardware buffer size, isn't it?
best greetings, Thomas
-
Thomas Grill -
Tim Blechmann