On Sun, 2005-06-19 at 15:02 -0400, Lee Revell wrote: A close second is bonehead vendors like Nvidia who STILL won't release enough information on their hardware to allow proper drivers to be written, which leads to infuriating bug reports of the form "it works fine in Windows so I know it's an ALSA problem, why don't you fix it already". Lee

you're almost right, if /dev/dsp is the thing for you, you should be allowed to use it. Unfortunately, for ALSA we have no finally DMIX available, but as soon as an application accesses /dev/dsp the application will hang or block the device for other applications, regardless if you have configured DMIX or not. AFAIK this is caused by technical reasons, and so I think: Any application that still uses /dev/dsp is an application that sucks. There are numerous ALSA applicaitons out there, so if you need example code use the advantage of free software and look into their code or even C&P. Not an offend, but a wish. Best regards ce

On Tue, 2005-06-21 at 19:06 +0300, Jussi Laako wrote: What in the hell are these newbies doing that they need to edit their asound.conf? It should just work. I have never had to touch one... Lee

although i broadly agree with these observations, it depends a little on what you think a "newbie" is going to do with a 1010. admittedly, the OSS situation is probably the best, although last time i looked i had the impression that you could open /dev/dsp in any particular configuration, but not multiple times. correct me if am wrong. more generally though, just what is the sensible default config for a multichannel card? its possible but a little far-fetched to suggest that its to be used as N stereo devices. the people buying 12 channel cards are doing it for a reason, and running it as 6 or 5 or 12 SB's is not the most likely one. this makes it hard to decide what the correct configuration is. i am think that on OS X, you get all channels by default and cannot choose otherwise. this is certainly true for the RME drivers (which cannot be used as stereo devices, although CoreAudio apps can play stereo streams through them). --p

True. But meanwhile there's kasound. Best regards ce

On Sun, 2005-06-19 at 12:42 -0700, Erik Steffl wrote: Fixed in ALSA 1.0.9. This was never really an ALSA problem. The confusion due to the large number of mixer elements is resolved with recent versions of alsamixer (by splitting the controls into Playback and Capture), and the Gnome 2.10 mixer now only displays the 4 or 5 most important controls by default. I agree that this is still a bug. Should be fixed in the next ALSA release. Until then it's trivial to work around, and could in fact be solved 100% in the mixer apps. No comment. Lee

At Sun, 19 Jun 2005 12:42:34 -0700, Erik Steffl wrote: This should have been improved. If you still have difficulties with the latest ALSA release, please report a bug. Agreed. I don't like it, too. Volunteers are appreciated :) Why don't you use cross-platform libraries if portability matters? It's much better than sticking with OSS API. Takashi

cool, I didn't notice it but to be honest I did update to JACK CVS just some days ago. About reconnecting I wonder if the applications could do it themselves and transparently as soon as JACK reappears. I did notice that it takes a lot of time to reconnect after I had to restart JACK. It may sound snottily but it simply would be convenient. Best regards ce

ix(a)replic.net wrote: Just found it it's been released! Awesome! OSC aware apps? wait, wait wait.. you can for sure use osc, but using jack and osc separatedly? That is like, a bad hack.. I mean, how do you know which host is what? Much less sync properly (read answers below) Right, Just checked on jack ML.. this is pretty amazing! What are you talking about? without frame-based precision you are relying on wathever jack server period size is, which means unreasonably forcing your apps to _really_ low latency for just "decent" accuracy. It is the same problem you have when you use alsaseq+jack. The typical hack to fix this is to have a separate thread receiving and timestamping events, but this is plain SHIT because you have to anyway rely on the lowlatencyness of the kernel to not jitter the alsa/osc IPC. I'm _NOT_ glad that jack concentrates only on audio, because I cant do that, share tempo maps, and many of the things described here. Come on!! *ANY* Comercial grade sequencer/daw/etc supports offline render. Like for example when you want to compose for movie/DVD, you need to use very high sampling rates/channels/etc that if you try to play in realtime would crawl your computer to death. So you just offline render the whole thing. But for more normal-composer uses, you probably want to render in high sampling rates and then downsample to reduce aliasing produced by several dsp techniques. Currently this is impossible with jack. I dont really mind if it is monolithic or not, I'm just noting that I need it, and I cant do it. Sure, you have to go and connect everything yourself, every time you start up, go to the shell find an empty console, run fluidsynth or wathever, have everything organized, etc. Basically the same as in the above point. Well, seeing how jack works i'm not sure if it does zerocopy because at some point it has to add up the connectons together, so I dont think adding sends per connection is impossible. Yes, ican probably make an inbetween proces that does a send, but this is annoying to use and probably reduces performance a lot more too. Because ardour for example, also has it's own tempomap and what I record on it wont fit. If i then change the tempo of my song or decide to do other changes (signature/etc), everything screws up. Yes, see what I mean, you have your point of view on the subject, so do API/lib/app developers. You could just go and argue about a lot of topics like: -Should jack support OSC? -Should apps be monolithic or a modular set of them? -Should audio/midi plugins separate UI from core in two processes or should it be integrated? -Should transport work frame based or BarBeatTick/etc? -Should we make a more advanced plugin standard and adapt it to an app, or wait for GMPI? -Should we use plugins at all? -Should we advocate for low latency, or better timing/syncronization so low latency is not needed as much? -etc, etc Everyone has their point of view. It's not like you will tell someone "I want to add this feature to your app/api" and will say "Ok". You will simply get an answers like: -No, sorry, I wont accept that patch, i'd rather the library concentrates only on this. -Why dont you do it as a separate library? -Feel free to fork this and add it yourself. -Yeah I recognize it's useful, but I think it's out of place, inconsistent with the rest, that I try to keep simple. etc, etc, etc. And forking of course is not an option. I mean it's a lot of work because you have to fork the lib, mantain it, recompile all the apps that use it against yours and not the main one, merge bugfixes and improvements to keep compatible. Also if you are using a distro, you cant use the binary packages because they are not compiled with your version of the lib, etc. So forking is not really worth it in most cases. Well, I dont have much time, nor I code very fast, but it's more like. I made Sequencer A, and softsynth B. They ar communicated thru library X. I want Sequencer A to do the things I want with softsynth B, both are my work. But library X doesnt support, it, so I go talk with library X developer and it seems there are no chances of that being implemented in the near future, or ever. So what do I do? I'm not left with much choice, Either I fork library X, or make A and B a monolithical app. The second is the easier/faster so I go for that. Juan

On Sun, 2005-06-19 at 22:22 -0300, Juan Linietsky wrote: Many people have made the same complaint, so you'll be happy to learn that JACK midi support was just committed to CVS a few weeks ago. I have no idea how you came to this conclusion, if you need a feature and submit a patch it certainly will be accepted. Lee

At 19:13 -0700 19/6/05, ian esten wrote: out of curiosity (and i'll go search the jackit archives too), how easy will it be to make Jacks' MIDI capabilities support non-ALSA MIDI libs, such as MidiShare? -- ; Jay Vaughan

but .. what about having Jack just use MidiShare Events (the 'other way around'), or is this a futile idea? /hasn't seen the jack-midi code yet, so i don't know what i'm talking about.. -- ; Jay Vaughan

Le 20 juin 05 à 14:33, Benno Senoner a écrit : I was only answering to the initial question of wether a MidiShare like API (where event scan have future timestamps, to be delivered at their due time to clients by the mean of a scheduler) could be built on top of the jack Midi API the way it is designed. And the answer is probably not. Stephane

would it not be possible to have the midishare to jack bridge buffer events that are timestamped in the future, and then schedule them in realtime in the process callback? ian On Mon, 2005-06-20 at 10:53 +0200, Stéphane Letz wrote:

Stéphane Letz <letz(a)grame.fr> writes: They would each need a scheduler, but that could be very simple. Maybe just a future event queue sorted by time. On each process() call, send the ones that apply to the current period. The trickiest part is handling the memory allocation and deallocation. Someone (perhaps libjack) could provide a standard set of functions to manage this, while still doing it all in the client's address space. The advantage is that future events are easily cancelled, when needed. -- joq

On Mon, 2005-20-06 at 13:06 +0200, Tim Orford wrote: 'Lack of support' problems. Though I am having a weird issue with restoring sessions, I'm not sure it's common.... -DR-

Paul Davis wrote: What is DLL-Driven? I used jack_frame_time() in chionic, It works, but it's not enough. It's dont mean that it's jack's fault itself. My experience with it was that I made a realtime ultrahigh priority thread for receiving alsa events and timestaming them, yet under high cpu, disk load (streaming sequence tracks to disk), or other conditions (ksysguard continuously monitoring the proc filesystem) the events that alsa delivered to me were jittered in a very noticeable way. I tried this in some machines with the same results in all. It works, just not in all cases. This is why I insisted so much in jack-midi lately. Yes found out about that after posting, congrats on it! I'll look forward to use it. Allow what? controlling your softsynths/effects with automation? I cant think of any platform that DOESNT support this. The problem is that under linux most programmers write softsynths/or gui-abled effect processors as JACK or JACK/ALSA clients, thus making it impossible to automate parameters of them. Jack doesnt provide any means for this. No, I think you dont understand that ALSA is not a part of JACK, ( I wrote jack/alsa above there) so you cant jack_freewheel with alsa midi events. However, since now jack will have midi, I'm glad this si not an issue anymore. I was refering more about having to run the applications yourself, and connect them later. qjackctl helps but I think it's still an annoyance. not to mention the console-only ones, where I need to have several consoles around. (at least for me) No, no, just in the connection itself. Imagine the following case: You have an app running a cpu-costly convolution reverb, it takes one input, one output. Then you have two softsynths (or one with individual ports) running two different instruments, a piano and a violin. How can I send both with different amounts of reverb to the convolution effect? I want the piano to have 75% reverb, because given it's characteristics, it will only increase the decay, but if i send too much reverb for the violin it will get muddy. In hardware synths or mixers, you allways have sends to achieve this easily. But you cant do this in jack because I cant determine how much of the signal i'm sending from one port to another. I talked with florian schmidt on irc about this, some time ago. But my impression from what he said is that most jack developers wanted to keep tempo map sharing in a separate library, not inside jack. I think he suggested that should be integrated, and I'd love to see it integrated too, as I beleive that would ease it's adoption. If you mean technically, I dont really know, as I dont know the internals of Jack. I really dont have the time to mess with that, and much less to discuss with other 5 developers about the most correct way to implement it. I am responsible for my own software, I cant be responsible for everything that doesnt work, or doesnt support what I need. I'm still using JACK, except that all the softsynths/effects, sequencer, and routing is done in-app, the monolithical way. (same as windows/mac apps). Please dont feel that I'm doing this because I'm offended or unhappy with everything. My way of seeing this is much simpler, it's that I cant rely on the existing APIs and APPs, and I feel that It's a lot more troublesome to deal with everything and everyone to get what features I need implemented, than simply doing it myself in a monolithic-fashion. Cheers! Juan

On Mon, 20 Jun 2005 09:50:53 -0400 Paul Davis <paul(a)linuxaudiosystems.com> wrote: There's none that i know of, but it would be cool to have anyways :) Up to now, due to the lack of jack midi it wasn't really possible to freewheel a complex setup (like several transport aware apps of which one is a midi sequencer which drives softsynths). And it will again take a while until jack midi has really been adopted. BTW: does jack midi work in freewheeling mode, too? Is there a design document for the Right Way out there? I would like to take a look.. or use one of the console driven patchbay programs, like jack_plumbing or jack_snapshot I agree with Paul here. Doing send/return/inserts, etc, is the job of a jack mixer app. The ardour mixer is a good starting point for this.. Here i would like to chime in :) I think the mapping of BBT to frames and the other way around isn't something that jack should be concerned about. IMHO jack should only provide transport based on frame numbers. Everything else, like different apps trying to agree with other apps which frame corresponds to which BBT should really be handled by a different mechanism. The reason for this opinion of mine is that musical time is simply too complex to be handled by one general mechanism. Think of different apps using different meters, etc.. Or even a single app using different meters on different tracks syncing to another app with yet another meter. I know, that dance music people for example would wipe this argument away, but there's more complex music out there :) [sorry, if i offended someone. I do not imply more complex == better]. IMHO the notion of BBT/tempo/etc. should be local to apps and if needed be shared via another lib (which, if it finally settled down and became quasi standard could again become part of jack). Now the question is about how this mechanism should look like. I'm not yet 100% sure, but i do have some ideas which i will ponder some more.. Flo -- Palimm Palimm! http://affenbande.org/~tapas/

On Mon, 20 Jun 2005 20:49:36 +0200 Tim Orford <tim(a)orford.org> wrote: I was thinking along the lines of having multiple tempo maps for this. App A is a sequencer having two tracks at two different meters (i'm thinking polyrythmic here, so the meters/tempi might be related (just to make a point about the usefulness of this)). Now there's Apps B and C. B should be in sync with A's first track and C should be in sync with A's second track. Don't know if this is really overkill though. I would find it useful.. Other features i would like to see would be smoothely (or non smoothely changing) tempi, etc.. The idea which lingers in the back of my head is not a "tempo map" as a structure which has meters/tempi for certain time ranges, but rather arbitrary mapping functions which map BBT -> frames and frames -> BBT (or even BBT -> time and time -> BBT and another pair od predefined mappings time -> frame and frame -> time). With this scheme an app could easily do linear or even nonlinear tempo changes, loops, etc.. These mapping functions can be "exported" by apps for other apps to use. (in the above example, A would export two mapping functions, one for each track. In the Apps B and C the user would then choose which of A's mappings to use). Again, no idea, if this is at all doable (fast enough ipc mechanism??) Yeah, i agree the mapping must be deterministic. I'm not sure it is atm (the jack_position_t struct carries ticks_per_beat and beats_per_minute info, but not frames_per_tick. It does have frame_rate though so ticks_per_beat could be derived from frame_rate, beats_per_minute and ticks_per_beat, but depending on how this calculation is done, different apps might come to different results. But this might be a non issue as the BBT info is updated by the timebase master in each process cycle. Arr, this whole thing is complex and i might be full of sh*t :) Flo -- Palimm Palimm! http://affenbande.org/~tapas/

On Mon, 20 Jun 2005 22:26:54 +0200 Tim Orford <tim(a)orford.org> wrote: True :) Except for the management overhead. Plus the added complexity for application developers which would have to present a choice to the user. And i surely was on crack when i wrote this. There's no efficient interprocess function call mechanism on linux (one of the reasons jack uses this fifo thingies to trigger execution of the clients' audio callbacks). Yeah, since directly calling the mapping functions is out of question, the mappings need to be "rendered". Hmm, then all the nice properties go out of the window. No, as one app provides it and another uses it. The editing has to be done in the app that provides the tempo mapping.. This remark i don't understand.. Flo -- Palimm Palimm! http://affenbande.org/~tapas/

In my opinion an application shoud remember the last used document and optionally reload it at start time... ...as well as optionally redoing audio and MIDI connections just like Hydrogen does. If an application saves this information to the config file as soon as it is known (looading/saving a file, doing connections), it is even crash save. I think that this is in the responsibility of a particular application instead of an additional external server. [...] I'm a normal user, but I was amazed when I started filiing bug reports and feature requests how many of them have been adopted. I never demanded on anything, I simply wrote "it would be nice if..." and I got very positive results (of course also some negatives, that's life). Best regards ce

you know what? there is plenty about the design to complain about, but when i complain about it, i willingly admit my own complicity in the mistakes that were made. ALSA has been under development for nearly 10 years. if you or others saw the "right way to do things" so clearly, why on earth didn't you speak up about it? how is the driver supposed to know? in general, the default values of these parameters works fine, but on linux, we reuse generic drivers all the time, and guess what? different audio/MIDI interfaces move the register/portIO addresses of common devices around. do you have a better solution? compiling a kernel to have both OSS and ALSA modules around makes a mess of many systems i've seen. and have you volunteered to help? have you put any time in to the numerous design discussions about the ALSA mixer API? why do you think it looks the way it does?

I can confirm that. Since I learned to build my own kernel and I disabled all OSS stuff I get much better results. As an example, I often received sysex packages the first three bytes missing. Disabling USB/usb-midi (which is in fact an OSS driver) resolved the problem. BTW: Any kernel hacker here? When disabling the OSS drivers completely, /usb/USB-midi and /USB/usb-audio should be also disabled automatically, and both options should be marked as "Deprecated" as OSS is. Any chance we incluzde this in the kernel config? Best regards ce

Takashi Iwai wrote: I'd like to clarify more on this. I'm not talking about deprecated old ISA devices (like one of those huge soundblaster 16 cards), not even isapnp but PCI devices which are being sold nowadays, or integrated into mainboards, more specifically, I dont understand why things like this exist: red@killy:~$ /sbin/modinfo -p snd-cmipci [ .. omitted non relevant options .. ] mpu_port:MPU-401 port. fm_port:FM port. joystick_port:Joystick port address. red@killy:~$ /sbin/modinfo -p snd-via82xx [ .. omitted non relevant options .. ] mpu_port:MPU-401 port. (VT82C686x only) red@killy:~$ /sbin/modinfo -p snd-ens1371 [ .. omitted non relevant options .. ] joystick_port:Joystick port address. Amongst many. These options exists in the soundchips for compatibility with old sound blaster card in MS-DOS, or win9x (which lets you access to ports directly). You can supply basically any of the allowed port values and they will work. They are legacy I guess, but it is still the only way that you can access to joystick/mpu401/opl3 in nowadays cheap soundcards. So, my main question is *why* isnt this autodetected by the driver/kernel by default? In my personal experience (and the alsa docs) these wont work until you supply some random port. I find this extremely user-unfriendly, because most sound users may not even know what a port is, much less that they have to do it. I mean, if isapnp does this kind of resource allocation, why it cant be done for this too? Thanks for your reply! Juan

On Mon, 2005-06-20 at 13:26 -0300, Juan Linietsky wrote: [stuff about manual IO post config deleted] Because unlike Windows, we don't have complete hardware specs, so lots of guesswork and trial and error is required. For example the SBLive! windows driver has an internal database that maps PCI ids onto the exact set of hardware features. We have to do a lot of guessing to get the same results. Lee