Since I was asked for:
Native driver increased to 0.5 http://iem.mhsg.ac.at/ritsch/programmier/
includes now the module-merge from miller and the alpha-patch from guenter.
mfg winfried
PS: Since the ALSA-Driver is out and looks quite well (based upon the native driver sources) its time to switch to ALSA soon.
- Anybody testing with ALSA and RME ?
I am not lucky enough to have one of these cards so I am not testing ALSA with the RME. I know, however, that the alsa code will not work in its current state. What is in pd .30 is just initial alsa support for 2in/2out that uses interleaving exclusively. As I understand things the RME card will not be able receive interleaved samples ever. My solution will be to add mmap support with both read/write and readv/writev - which will hopefully offer all of the performance of your native driver using alsa drivers. Any volunteers to do testing to the code when I am finished?
Karl
Winfried Ritsch wrote:
Since I was asked for:
Native driver increased to 0.5 http://iem.mhsg.ac.at/ritsch/programmier/
includes now the module-merge from miller and the alpha-patch from guenter.
mfg winfried
PS: Since the ALSA-Driver is out and looks quite well (based upon the native driver sources) its time to switch to ALSA soon.
- Anybody testing with ALSA and RME ?
[...]
using alsa drivers. Any volunteers to do testing to the code when I am finished?
for sure, I will,
I saw you used stream mode too, maybe there is an answer.
The point is normally different devices are not synced by default but on hammerfall devices they are, so this could be a trap for unexperient user if the alsa-part just uses every alsa-device it finds. we need some kind of selection method...
mfg winfried
Can someone explain to me the pros and cons(if any) of ALSA???? I am still in the embryo OSS drivers and would like some help as it might pertain to better sound ..........
Winfried Ritsch wrote:
[...]
using alsa drivers. Any volunteers to do testing to the code when I am finished?
for sure, I will,
I saw you used stream mode too, maybe there is an answer.
The point is normally different devices are not synced by default but on hammerfall devices they are, so this could be a trap for unexperient user if the alsa-part just uses every alsa-device it finds. we need some kind of selection method...
mfg winfried
....
Can someone explain to me the pros and cons(if any) of ALSA???? I am still in the embryo OSS drivers and would like some help as it might pertain to better sound ..........
... ok
- ALSA will be the sound driver in future in kernel and oss is thrown out
- ALSA is free OSS is not, OSS-free is always 2 years behind
- ALSA has a multichannel concept, OSS only stereodevices (as far as I Know)
... X) for ALSA there is a lib, for OSS not. Y) ALSA is SMP-ready i think, oss... ? Z) There a lot of soundcards supported by ALSA
... anyway better sound lies in the ears of the ...
mfg winfried
I just installed linuxPPC 2000 on a beige G3, downloaded PD .30, compiled it, and it ran perfectly (after setting the -frags flag to force old OSS behavior). Haven't tried full duplex because the built-in sound input isn't connected (as it has an audiomedia and motu 2408 I'm surprised the built-in sound out was connected). I know others had problems in the past but they seem to have been resolved. I will put a binary up at www.peabody.jhu.edu/~karlmac/download later tonight.
Karl
| Karl W. MacMillan | | Peabody Institute of the Johns Hopkins University | | Network and Telecommunications Services | | karlmac@peabody.jhu.edu | | 410/659-8297 |
ppagano@bellsouth.net wrote:
Can someone explain to me the pros and cons(if any) of ALSA???? I am still in the embryo OSS drivers and would like some help as it might pertain to better sound ..........
Perhaps the biggest advantage of the ALSA drivers is that they will be the official sound drivers included in the linux kernel starting with the 2.5 kernel series. Otherwise they are SMP safe, are designed from the ground up to provide low-latency playback/capture, have an API that is extensive enough to support cards with a large number of channels, easily deal with digital i/o, and provide a library to make pogramming easier. They also provide excellent emulation of OSS so that an application, including PD, can use ALSA drivers in OSS emulation mode.
Karl
Winfried Ritsch wrote:
[...]
using alsa drivers. Any volunteers to do testing to the code when I am finished?
for sure, I will,
I saw you used stream mode too, maybe there is an answer.
The point is normally different devices are not synced by default but on hammerfall devices they are, so this could be a trap for unexperient user if the alsa-part just uses every alsa-device it finds. we need some kind of selection method...
mfg winfried
There is definitely a need for some way to select which pcm devices the user would like to use but I don't have a good solution at the moment - I don't want to the require the user to have detailed knowledge about the pcm devices on their card and set lots of command line switches just to get useful default behavior. Any ideas?
As for the sync, I plan to move to mmap block mode for the default which will allow access to the pointer position in the ring buffers on the card so that sync can be maintained. As long as only one card is used there shouldn't be a problem. Am I thinking about this correctly? Another reason to move to the mmap mode and avoid the plugin layer is it is possible that the ALSA library will insert sample rate conversion, interleaving, etc. when using the plugin api. This is great for most applications but probably bad in the case of PD. Stream mode using the direct layer will be maintained as an option.
Karl
-
Karl MacMillan -
Karl W. MacMillan
-
ppaganoļ¼ bellsouth.net -
Winfried Ritsch -
Winfried Ritsch local