On Sat, May 08, 2010 at 06:23:10PM -0400, Paul Davis wrote: I'm using an EWS88MT on a 2.6.33 system, Alsa 1.0.22, and it works as expected. Cards such as the EWS88MT provide 8 identical AD/DA channels (also the connectors and signal levels are all the same), and there's no way PA or any other audio subsystem could determine which ones are e.g. 'stereo playback'. This should just be left to the user to configure, including the option "don't ever use this card". Ciao, -- FA O tu, che porte, correndo si ? E guerra e morte !

On Sat, 2010-05-08 at 18:23 -0400, Paul Davis wrote: I think you are correct. Pulse points to alsa as the culprit, alsa ignores the issue, it may _not_ be an issue for alsa, I don't know. The end result is that it has not been fixed and it has been quite a while. I have a workaround in place for my machines at ccrma... -- Fernando

On Mon, May 10, 2010 at 3:52 PM, Hartmut Noack <zettberlin(a)linuxuse.de> wrote: PA is specifically for 'desktop' usage, pro-audio isn't a part of that. If you're doing pro-audio you'd be running JACK anyway. I struggle to understand why a user would want PA, with all the inherent latency concerns (compared to JACK) to control their pro-audio soundcard.

On Sun, 2010-05-09 at 23:34 -1000, david wrote: ???

On Sun, 2010-05-09 at 23:41 -1000, david wrote: Paranoid? ;) No, here Pulse nicely suspends when I start qjackctl and not vice versa... Jack rules here ;) \r

On Mon, May 10, 2010 at 5:41 PM, david <gnome(a)hawaii.rr.com> wrote: Yeah, world domination is ALWAYS on the agenda I'm sure. Which is why Pulseaudio automatically suspends its control of a sound card with jack2 requests control =)

On Mon, 2010-05-10 at 10:00 -1000, david wrote: For reference (not specifically directed to you), more recent versions of Pulse (not sure exactly which) and jack2 (jackdmp) cooperate in that form. Recent distributions should have it sorted, unless they're using jack1.

Ng Oon-Ee <ngoonee(a)gmail.com>om>: AFAIK, suspending PA works with qjackctl, not directly with jackd. just by running qjackctl, PA suspends. if you run it from the terminal, you'll see "Suspending PulseAudio". this means PA is suspended even if jack is not running - only qjackctl. this also means, jack CAN run while PA is running. i do this frequenlty as i start jack from the command line using firewire audio interface. jackd -v -R -t1000 -dfirewire -r44100 -p128 -n3 so i can do pro-audio through fw and still have flash movies playing in firefox. and hearing them. it is also simple to suspend PA on the command line, something like: pasuspender -- jackd -R -t1000 -d alsa -r44100 -p512 -n3 l -- sujet est machinique! Nova deViator ¤ http://deviator.si ¤ http://skylined.org ¤

Luka Princic // Nova deViator wrote: I have all audio on my laptop playing through the USB sound card, including Flash in Firefox. -- David gnome(a)hawaii.rr.com authenticity, honesty, community

On Mon, 2010-05-10 at 11:32 +0200, rosea.grammostola wrote: It would be nice for it to support suspend/resume properly, but other than that it works fine for me. It does have the oddity that it can only be opened with 12 in and 10 out channels, but that is how the chipset works, and it would indeed require 'hacks' in the userspace side of ALSA to work around this for PulseAudio. -- Peter

On Mon, May 10, 2010 at 6:40 AM, Hartmut Noack <zettberlin(a)linuxuse.de>wrote;wrote: I think you should STOP immediately labelling Lennart and anyone else involved in PulseAudio. You simply don't know what they know. Lennart is actually much more familiar with what pro-audio/music creation needs are than the vast majority of posters on this list are about the issues faced by desktop and mobile audio. Many posters to this list also display a remarkable level of ignorance about how PA actually works, how it is configured and what it can do.

On Mon, 2010-05-10 at 07:30 -0400, Orcan Ogetbil wrote: You know, perhaps I should demand Linus and the kernel hackers stop wasting my time by releasing those broken kernels which just dump me on grub. The 2.4 series worked just fine for me....

On Mon, May 10, 2010 at 08:31:46PM +0200, Hartmut Noack wrote: Which is logical, as it is not his priority. But neither does he ignore pro-audio. As one who has commented on PA before I may be allowed to say this: I do *not* hate PA. I just don't need it, since I do not want any 'desktop' sounds on my machines, and I expect to be able to set up a system without PA just as I can set up one without CUPS, or without RAID, or replace Sendmail by Postfix, or in general choose whatever subsystems I actually need. What I *do* hate is that this has become near impossible with major distros, since the way they set up 'a destop system' makes almost everything depend on everything else, regardless of such dependencies being real or not. A mail program is still fully functional even if it doesn't start singing whenever a message arrives, and it should be installable without any dependency on anything audio. That this is not the case is not Lennart's fault. That he actually seems to advocate this type of distro policies is another matter, I can't explain it on rational grounds, and it is the main reason behind my negative reactions towards him at some time. Apart from that, *if* you want 'desktop sound' then PA is probably the best thing since sliced bread. I was *very* surprised to learn that PA at the moment does not have a native API, at least not one Lennart would want to advocate. PA would gain a lot of appeal by providing that. Regarding user ignorance of PA's qualities and configuration options, that is partly the result of what the 'desktop movement' aims to provide. If everything is designed to be automatic and zeroconf then the logical result will be ignorant users. Ciao, -- FA O tu, che porte, correndo si ? E guerra e morte !

On Mon, 2010-05-10 at 22:47 +0200, Philipp Überbacher wrote: I believe Lennart mentioned that the API is not yet totally stable? Apps do use it, however, and they will have to be updated if it changes. That's my understanding, in the least.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 10.05.2010 22:20, schrieb fons(a)kokkinizita.net: And distro-vendors do not have such a priority either. But audio-production is a standard-feature for Mac and Windows so in my humble oppinion: Linux will never be considered a mature universal usable operating system if it does not support audio-production. To set up any standard-Linux for that task is done in a matter of minutes today and it makes my stomach turn seeing that distributors are not giving even that little effort to make it possible. A little post-install script for a jack-package that sets up group audio and limits.conf. Ubuntu actually tries to do that but fails to put the user into group audio and to set memlock. And if there would be a graphical, well documented tool easy to be found and easy to operate tool to setup PA, everything could become much much easier and the hatred would fade... This I argee absolutely. PA has the potential to solve all the trouble with Linux Audio on the desktop for good. Again I agree from the heart. I filed a bug report in ubuntus launchpad some years ago, complaining, that startup-messages are not displayed anymore but only a MacOSXish progress-animation. The Ubuntu-people answered that "thousands of users" had complained about "scary messages scrolling by at startup". So they removed them. We then found an agreement that hitting SPACE or ESC should display the messages for those, who are not so scared about informations about the startup process. But still you can only change to another console to see whats happening in UBUNTU as it starts. best regards HZN

Excerpts from Hartmut Noack's message of 2010-05-10 20:31:46 +0200: I'll only comment on this part. Either it's a lack of documentation, and hence you don't know how to use it, or a packager messed up. I have little interest in PA, but out of curiosity I tried to get it to play together with jack. It's actually not that hard. It's documented here: http://wiki.archlinux.org/index.php/Pulseaudio#Pulseaudio_through_JACK I just added the temporary variant, which is as simple as: 1) start jack 2) start PA with: pulseaudio -L module-jack-sink -L module-jack-source 3) done. -- Regards, Philipp

On Mon, 2010-05-10 at 12:40 +0200, Hartmut Noack wrote: If I'm not mistaken, the fixes wouldn't touch the actual driver at all, merely how inputs/outputs are labelled (in other words, labelling them properly). Nothing which would affect JACK at all, nor pro-audio use.

On Tue, 11 May 2010, ailo wrote: m-audio delta cards are ice1712 cards. http://alsa.opensrc.org/index.php/ice1712 -gabriel

On 05/11/2010 03:58 PM, Gabriel M. Beddingfield wrote: To clarify, I meant to ask if chips, other than ice1712 are affected.

On Tue, May 11, 2010 at 10:08:20AM -0700, Fernando Lopez-Lezcano wrote: Given that PA aims to be a desktop audio server catering for the 'standard' formats such as stereo and 5.1, it really can't be blamed for not knowing what to do with a card that presents N (N >= 8) identical channels. And I'm somehow surprised if users of such cards (who probably use Jack anyway) expect PA to handle this OOTB. The obvious solution for them is to use the PA<->Jack bridge which is reported to work well. Ciao, -- FA O tu, che porte, correndo si ? E guerra e morte !

On 05/12/2010 12:47 AM, Fons Adriaensen wrote: So, Pro Cards were not intended for desktop audio. In the end they are just computer devices that output sound, which we all expect them to do.

Hartmut Noack wrote: It would still be a trouble-maker. There's no guarantee that the first 2 ports of any such multi-port card are being routed to what PA would (presumably) be assuming are the appropriate stereo channels out. IMHO, the obvious solution would be for them to simply stop wasting their time on PA and make an existing and better solution (JACK) better. ;-) -- David gnome(a)hawaii.rr.com authenticity, honesty, community

Excerpts from Paul Davis's message of 2010-05-12 13:16:23 +0200: I strongly believe that this is PAs biggest problem, trying to do too much at once and not getting anything really right. Ok, it's not really trying to cater for pro-audio/music creation, but it tries to do everything else at the same time, even low latency (for different purposes). I simply don't think that it can do the mobile thing and the desktop dance at the same time, since it is still very different. Mobile can be a lot simpler in many ways. You pretty much only ever need 2 channels, it doesn't need to be flexible, latency doesn't matter at all, it just needs to be there and not get in the way CPU, memory and power wise. For this PA is already way too complex, but PA still tries to do it and save cycles wherever possible. At least that's the way I imagine it. The desktop on the other hand needs a lot more flexibility, there are endless possible user needs. Low latency is needed for games, subtitle synchronisation and other weird stuff. Multichannel is needed in at least the common variants. Proper controls for everything are needed. It needs to be simple to setup and use. Network stuff is needed. cpu/mem/power usage is far less of an issue than with mobile devices. PA tries to do all of this at once, and at least on the desktop it fails often enough. Sure, many user complaints are old and the problems might be solved, but many users are fed up with it already and don't ever want to try it again. It just couldn't deliver what it promised most of the time. Premature adoption of major distros sure didn't help. If I recall correctly Lennart was very surprised to hear that ubuntu had adopted PA as default soundserver about two years ago (was it 8.04?). There's a fun German expression that fits PA quite well: "Eierlegende Wollmilchsau" Maybe it would work better if it didn't try to do everything at once. -- Regards, Philipp

On Wed, 2010-05-12 at 09:14 -0400, Paul Davis wrote: The other group of people who are fed up are those who had problems with the early PA-releases in various distros (Ubuntu mostly), solved them by removing PA, and have since them removed PA on every install/upgrade. Of course, this starts causing problems, which are then blamed on PA, even though the original issues which caused them to want to remove in the first place have been fixed. Its amazing how single-minded Linux users can be over something like this. Isn't a big part of Linux choice, flexibility, and all that? Btw, off-topic, its amazing to see the author of JACK defending PA, since most of the time I hear JACK-pros dissing it.

On Wed, 2010-05-12 at 09:20 -1000, Joel Roth wrote: The catch-22 here is that for PA's autostart feature to work (and it has to if things are to 'just work' on your typical Ubuntu install) there's quite a few places where it needs to 'hook' in. This is a general Linux thing, and because PA is not an app which the user is expected to manually start, there's various autostarts for PA embedded in your system. Having a 'disable PA' button is fine, and I think Mandriva does it (hearsay), but it adds a lot of burden on the maintainers. Do you default your standard apps to PA support (which works better if PA is running but doesn't work with standard ALSA at all) or to ALSA (which hopefully runs the same both with or without PA, but doesn't then take advantage of PA features such as sound-category-labelling). Should BT headsets just not work once PA is disabled (previous method in ALSA requires setting the ID in .asoundrc manually, will a script be written to do that)? Does the 'disable PA' button also have to reconfigure all audio apps such that they output to ALSA instead of PA? And one of the reasons problems show up on PA when ALSA 'just works' is that PA is using parts of the API which no-one else uses. Which is how we actually got into this whole thread in the first place. So no, a 'disable PA' button wouldn't help to isolate things, but just reinforce the notion that PA is causing the breakage. At the cost of additional work and complexity (thus more room for bugs) for maintainers.

On Wednesday, May 12, 2010, Paul Davis wrote: It would be nice if you make a similar public declaration about Jack MIDI and ALSA sequencer. http://wiki.linuxaudio.org/faq/start#qwhat_is_the_difference_between_jack-m… "The short answer: Jack-Midi has been introduced to extend/replace alsa-midi [...] They currently co-exist." Looks like somebody dreaming of world domination. Regards, Pedro

On Wednesday, May 12, 2010, you wrote: MIDI and Audio are not directly related, either. The ALSA sequencer API may be implemented in user space, offering a way to existing applications to be used with the new sequencer in a transparent way. That would be nice and consistent with our (Linux audio users) priced freedom of choice. I know that it is not the easy path, but would be consistent with the efforts of the ALSA people providing an OSSv3 compatibility API. Not only that, but Jack MIDI forces to the MIDI applications to always be used subordinated to an audio stream. Even when you don't want to use digital audio at all, because your MIDI sources and receivers are all external musical instruments. Another drawback is that if you want to succeed replacing an existing API, you need to provide at least every functionality provided by the old one, and do it in a nice way that can be adopted easily by the developers. I understand that the ALSA sequencer API is huge and cumbersome, but the minimalist approach of Jack MIDI may be just another mistake in the opposite direction. Regards, Pedro

On Wednesday, May 12, 2010, Paul Davis wrote: This discussion about dry technical details don't really belong in this mailing list. Maybe you would prefer to transfer it to LAD? But on the other hand, the functional aspects are all on topic on this list, because what the users want is functionality, and I doubt that someone care too much if something is implemented in the kernel or in userspace, if it works well and there are applications fullfilling their needs. Jack MIDI is good for real time usage, specifically when using it to build real time MIDI synthesizers. Aside from MIDI controller applications, ALSA sequencer provides good queueing and scheduling, features very useful to create MIDI players. For this usage, event time units can be musical time instead of seconds or frames, for good tempo control and flexibility. Returning to the topic of PulseAudio, I want to praise their developers for the effort in keeping compatibility with the old esound daemon and supporting ALSA/OSS applications transparently; this has not been an obstacle to provide also a new native API. Regards, Pedro

PA or not, this is somewhat getting back to the original question: how can we get a reliable index assignment on startup with several soundcards. I'm not using PA, but mostly because I noticed that it uses (much) more CPU with many desktop applications, due to resampling I was told. I have an internal HDA, an nvidia graphics chip, a nanokontrol and a UA-25. The latter both use snd-usb, though one obviously cannot produce sound. The nvidia chip seems to expose an audio device (?) handled by a snd-hda-intel module, as does the snd-hda-intel soundchip. Although the first one cannot produce sound. So I would like the following order to be maintained to have desktop applications adress a working soundcard and to have the UA-25 always at the same index for JACK.  0 [Intel          ]: HDA-Intel - HDA Intel                       HDA Intel at 0xfbff8000 irq 32  1 [NVidia         ]: HDA-Intel - HDA NVidia                       HDA NVidia at 0xfde7c000 irq 16  2 [UA25           ]: USB-Audio - UA-25                       EDIROL UA-25 at usb-0000:00:1d.0-1, full speed  3 [nanoKONTROL    ]: USB-Audio - nanoKONTROL                       KORG INC. nanoKONTROL at usb-0000:00:1d.0-2, full speed The way I found after some trials with module inits was: 1) in /etc/modprobe.conf: options snd-hda-intel index=0 options snd-usb-audio index=2 This fortunately always puts the UA-25 at index 2. However, the first option does not work, since the nanokontrol seems to get recognized before the HDA device and it is often sitting on index 0. So I found that adding snd_hda_intel to /etc/modprobe.preload does the job, this way the intel module appears before the usb module... Now my question is: is there any better way to do this? Is there a way to distinguish further than only by the module name for the index? How could this be solved more generally? I guess PulseAudio has the goal to handle such issues, and once it gets there without side effects, this seems an important goal. But if I understand right, it does it by id attribution in a layer on top of this. If it's only that index shuffling, why can't alsa or the kernel be more predictable? BTW when I tried PA here together with JACK, the device reservation worked very well. Frank

On 05/13/10 08:56, Frank Kober wrote: You need some sort of unique identifier for a sound card. With the RME cards that was easy, as they have individual serial numbers, which I add to the card's name: HDSPe_f1cd85, for example. I did this because in the setups those cards are used in, it is absolutely mandatory to identify the cards (probably multiple cards of the same model) correctly. In the hw: argument you can use the card's name. As you only have one 'UA25', this should work: jackd -d alsa -dhw:UA25 Flo -- Machines can do the work, so people have time to think. public key DA43FEF4 x-hkp://wwwkeys.eu.pgp.net

On Thu, May 13, 2010 at 10:03:58AM +0200, Florian Faber wrote: Wouldn't the right way to do this be to let udev find out the serial number and then define the name that includes/uses it ? (not sure if the latter is possible, but reading the SN from /sys should be) Ciao, -- FA O tu, che porte, correndo si ? E guerra e morte !

On Thursday, May 13, 2010, Frank Kober wrote: You can specify the order of the two USB audio devices adding to the options line the 'vid' and 'pid' arguments, which are arrays like 'index', up to 8 elements. The 'vid' argument corresponds to the idVendor and 'pid' to the idProduct hex numbers shown by lsusb. For instance, I have this line: options snd-usb-audio index=1,2,3 vid=0x0763,0x0582,0x0582 pid=0x1110,0x0005,0x00a3 idVendor = 0x0763 is Midiman and idVendor = 0x0582 is Roland. Regards, Pedro

On Thu, May 13, 2010 at 1:53 AM, Paul Davis &lt;paul(a)linuxaudiosystems.com&gt; wrote: Still, I've used the current PulseAudio callback-driven API, and it isn't the most felicitous API but it certainly works. I've been thinking of adding a driver for it to Rosegarden, just to wind people u-- sorry, I mean to get basic playback working on systems without JACK. Perhaps fortunately, as always I haven't managed to find the time. I've just spent a few minutes configuring PulseAudio on an Arch Linux system that didn't originally use it, and I have to say that if your workflow includes blips, bloops, media players, and YouTube as well as "serious" audio applications, it really does help to have Pulse working right. It's the badly configured or incompletely installed Pulse that you really have to beware of, and if that's your problem, it's just good as a principle to learn how it works and how to fix it rather than to assume that its developers have simply been wasting far more of their time than you ever will on it. A lot of readers here would find it enlightening to find out what it really consists of and how you make it work properly: I certainly have; it's a fascinating system. And it's not hard to get every type of "desktop" audio playing through Pulse, and then have the whole thing step neatly aside when you want to do real work with JACK. Of course I accept that for many readers here "desktop" audio is of less than no interest, but for some it may be. The real problem PulseAudio has is that you will curse Lennart for the entire time it isn't working properly, and then totally forget about it when it is. Chris

On Thursday, May 13, 2010, Paul Davis wrote: Yes. With the appropriate mindset, even using a minimal set of very low level operations you can write any program. Why should I adopt any new API for my programs in replacement of a good old one that gives me everything I need? Maybe because we love to try new toys, and there was a good marketing campaign selling me the idea?... On the other hand, I tend to ignore campaigns exhibiting a motto like "resistance is futile, you will be assimilated". Regards, Pedro

On Wed, 12 May 2010, Pedro Lopez-Cabanillas wrote: When writing MIDI apps, I want to deal with a normalized, time-stamped MIDI byte stream (like what JACK MIDI) gives. I really dig the JACK MIDI API because it gets out of my way and lets me do my job. I never liked the ALSA MIDI API because it was trying to do too much crap /for/ me. I have to spend a bunch of time grepping through source code (because the docs suck) trying to undermine the ways its trying to help me. $ 0.02 -gabriel

On Wed, 12 May 2010, Paul Davis wrote: Ha! No, that's what I meant. :-) For example, when implementing a MIDI CC the flow of my code will be something like this: [3 bytes MIDI] -----(ALSA)----> snd_seq_event_t snd_seq_event_t ----(GABE)----> [3 bytes MIDI] + timestamp I would say that this is undermining the ways it's trying to help me. I could drop the seq API and use the raw MIDI API, but then I lose the time-stamp. (Unless I've misunderstood something somewhere....) In contrast, the JACK MIDI API is something like this: [3 bytes MIDI] ----(JACK)----> [3 bytes MIDI] + timestamp Which is beautiful. :-) To further rant on the ALSA seq API.... snd_seq_event_t is a complex, C-style, polymorphic type. So, instead of the CC param & value being a simple buf[1] & buf[2], it's event->data.control.param and event->data.control.value. If you have a different type of MIDI event... it has a different API... which means you have to spend a lot of time with the not-so-hot documentation. -gabriel

cheap 5.1 channel 1723 "Via Tremor" available in a zillion configurations and boards -- the only reason I bother with this P.O.S. is that it has a waveterminal header for my Yamaha DB60XG), I've learned this is an issue that affects a lot of people and not only prosumer cards like the M-audio Delta (ice1712) but also low-end and including built-in to motherboards and media stations: This particular card for example is documented as working with the following ( http://www.kernel.org/doc/Documentation/sound/alsa/ALSA-Configuration.txt): Module snd-ice1724 ------------------ * MidiMan M Audio Revolution 5.1 * MidiMan M Audio Revolution 7.1 * MidiMan M Audio Audiophile 192 * AMP Ltd AUDIO2000 * TerraTec Aureon 5.1 Sky * TerraTec Aureon 7.1 Space * TerraTec Aureon 7.1 Universe * TerraTec Phase 22 * TerraTec Phase 28 * AudioTrak Prodigy 7.1 * AudioTrak Prodigy 7.1 LT * AudioTrak Prodigy 7.1 XT * AudioTrak Prodigy 7.1 HIFI * AudioTrak Prodigy 7.1 HD2 * AudioTrak Prodigy 192 * Pontis MS300 * Albatron K8X800 Pro II * Chaintech ZNF3-150 * Chaintech ZNF3-250 * Chaintech 9CJS * Chaintech AV-710 * Shuttle SN25P * Onkyo SE-90PCI * Onkyo SE-200PCI * ESI Juli@ * ESI Maya44 * Hercules Fortissimo IV * EGO-SYS WaveTerminal 192M revo51, revo71, amp2000, prodigy71, prodigy71lt, prodigy71xt, prodigy71hifi, prodigyhd2, prodigy192, juli, aureon51, aureon71, universe, ap192, k8x800, phase22, phase28, ms300, av710, se200pci, se90pci, fortissimo4, sn25p, WT192M, maya44 Unfortunately my $5.00 card http://alsa.opensrc.org/index.php/Ice1724#Dynex_DX-SC51, though claimed to be supported in ALSA isn't supported very well because there's no special-case code telling how many DACs, how many MPU401 ports, etc: IRQ 19 Fortunately, when I play one of the Yamaha XG wunder-midi ( http://www.blueman.name/Creations_XG.php ) through this $5 Dynex -- really just a glorified holder for my Yamaha db60xg --I hear shredding on my headphones and I know all is well: "aplaymidi -p 40:0 vchile.mid" :-). Or as I told my sister, "best damn $20.00 synthesizer I ever bought"... reply: "twenty dollar synthesizer" that sounds like a good band-name! With the above error message the Dynex comes up in a minimal 2-channel mode... trying different similar model= configurations, jackd pukes all over the place (sometimes locking up the machine trying to open 8 dacs when only 6 available etc)... I finally got SPDIF working, using 'plug' to keep it from balking at source-material that isn't in the exact same S32_LE bitformat needed by the card. Checking the sourcecode to see what was up w/ it's total lack of 5.1-ness, and also to decide which model= variants to try, I noted a giant unworkable pain in the butt (this "1712" code also includes the 1724): http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=tree;f=s… This results in all manner of problems and workaraounds for very minor variants of essentially the same chip: http://envy24.svobodno.com/ (mine's not on there boohoo). Multichannel sound is a big problem, with the following as good proof: http://ubuntuforums.org/showthread.php?t=843012 Also a problem -- digital outs, both under ALSA and pulseaudio: http://alsa.opensrc.org/index.php/DigitalOut I think it all needs to be solved, once and for all, across-the-board without dividing into camps and pointing fingers. -- Niels http://nielsmayer.com