Paul Davis wrote: Old OSS/Free may have this kind of ioctl calls. However OSS 4.x has similar control API than ALSA. MADI clock source is one of the "big red button" controls in OSS. They are supposed to be touched only when the whole studio wiring changes. This is to be done in the control panel by the system administrator. There is no point in letting any application to change such settings so it has intentionally been made pretty much impossible. Best regards, Hannu

Fons Adriaensen wrote: You missed the point. With OSS you can change the sync source any time you want by launching the control panel (ossxmix) and by changing the control exposed by the driver. If you do the change incorrectly it's all your fault. However it has been made almost impossible to make this kind of changes from your audio application (say media player). With OSS you may have up to 32 different applications playing audio at the same time with MADI. If some of them changes the sync source on fly it will break everything. Such uncontrolled changes might (for example) drop whole radio station off-air. Application programmers seem to be very innovative when inventing wrong solutions to problems they encounter. I would not be surprised in some application has a comment like: /* * There seems to be a bug in OSS. It doesn't permit changing the sampling rate if the sync source is set to * external sync. As a workaround we can try to switch the device to internal sync before setting the rate. */ By making this kind of changes pretty much impossible we can prevent programmers from doing stupid mistakes. Before ading this kind of stupid workarounds they will probably ask somebody to help them. In this way there is a chance that somebody with better knowledge can stop them. Best regards, Hannu

Fons Adriaensen wrote: Right. The driver or the hardware itself can do this transition automatically when it's required. The control panel will reflect this change in way or another. However there is absolutely no idea in implementing this kind of functionality in more than one application. The control panel program shipped with the sound subsystem can do the change out of box. If a MP3 player (or whatever) implements support for this kind of control then does it make the world better? ALSA's design philosophy has been to expose all aspects of the sound hardware to the applications so that they can play with any of them. This is all bullshit. All audio applications have some kind of audio stream to play/record (with given sample rate/format). This is all they should care about. It's responsibility of the audio subsystem to ensure that the stream is properly converted to match the capabilities of the actual device. Applications can (optionally) check if the device supports 192 kGz/32 bits/64 channels before giving the user a choice to use such format. However in the OSS model they are not required (or supposed) to do this. OSS will automatically do the conversions or to return an error if the requested rate/format/#channels combination doesn't make any sense with the current device. If you look at any kernel level subsystem such as networking or access to ordinary disk files. None of such applications want to know anything about the actual hardware details. I have not seen any PHP or CGI scripts/programs that try to switch the NIC card to use 1 gigabit signalling rate instead of the 10 mbit one supported by the network HUB. Why should any audio application be different? Best regards, Hannu

Fons Adriaensen wrote: Which one of the applications should do this? There may be up to 32 applications playing to individual stereo pairs of the MADI interface. The same is true with recording. They may be file players, samplers/synths, VoIP links, DAW applications or whatever. Should each of them have a timer callback that checks the sync source and turns it back to original if it has changed? How do you ensure that all applications push to the same direction? Or maybe you have this functionality in your hypercharged allmighty application that spends all it's time in babysitting the hardware. This kind of workarounds belong to the hardware/firmware or the driver. They should be clever enough to take the clock from their internal DDS/PLL while the external clock is absent. If this problem is not handled in hardware/driver level then you can simply use a script that runs in background and does "ossmix syncsource MADI" once a second. The same can probably be done using ALSA's command line tools. There is no point in reinventing the wheel in many applications. And what might your application do? I agree that there are cases where special purpose programs need to control the hardware directly. However applications that open /dev/dsp or /dev/midi must not try to go down to the hardware. In the OSS model practicaly all hardware level controls are hidden behind the control panel interface. It is possible to implement special purpose control applications that use this interface. For example a control application may monitor the sync locked status and measured sampling rate of an AES/EBU input. When sync goes on it launches a DSP application that creates the filter tables for this particular sampling rate. When somebody disconnects the input the control application ramps down the output level and kills the DSP program. When something else gets connected to the input the new sampling rate will be measured and then the DSP program gets launced again with proper parameters. The DSP program doesn't know anything about this. It can be used with any sound card (say ICH). The control program doesn't know what the actual application does. It just knows how to monitor given input of specific sound card model and to insert -s<rate> to the command line when it starts the app. Both programs can be used alone, together with each other or even with some other programs. Best regards, Hannu

On Sun, Nov 16, 2008 at 11:51:12AM -0500, nescivi wrote: That's correct, but only part of the picture. The system will be used in two roles, as a permanent installation in a museum, and as a research tool. In the first role it has to work unattended day after day, surviving power and network interruptions and everything else that could go wrong. All the museum staff will see is a 'player' like telecommand GUI on a computer at the reception desk. The system is on its own, and not only when I'm taking a break. In the second role it has to be completely flexible and reconfigurable. It should be able to resume the 'museum mode' with a single mouse click when the researchers are done using it. For this reason, they are not allowed to modify any physical wiring, and all signal routing including clock distribution must be under software control. In the future the system may be connected (by optical links) to other installations in the same building and also to a concert hall or recording studio a few km away. This again has to be remotely controlled, and of course may involves switching, among other things, some clock sources. Ciao, -- FA Laboratorio di Acustica ed Elettroacustica Parma, Italia Lascia la spina, cogli la rosa.

On Mon, Nov 17, 2008 at 12:14:32AM +0200, Hannu Savolainen wrote: That is exactly what I'm doing, and I have already told you at least three times. That 'dedicated program' is still _an application_. And no, it can't be 'a simple script' it is doing a lot more than you can imagine - including configuring a lot of external hardware, sometimes directly, sometimes by talking to daemons on other machines, etc. etc. It doesn't have to work with any other card. We are relying on the functionality of very specific external hardware anyway. Unless you know a replacement for e.g. and RME ADI648, and you can 'abstract' both this and the ADI648 to the same remote control API without any loss of functionality. Ciao, -- FA Laboratorio di Acustica ed Elettroacustica Parma, Italia Lascia la spina, cogli la rosa.

On Saturday 15 November 2008 07:22:16 pm Hannu Savolainen wrote: So the solution is to say "stupid application programmers, they can't be expected to know any better", and then hardwire logic into the driver system to force it to use the behavior appropriate for an MP3 player? I'm not sure that this is a smart design tradeoff. Actually, I can think of cases where something like that could be extremely useful -- a network analyzer or monitor, for example. It's not a common requirement (just as altering the sample clock sync source is not a common requirement for most audio apps), but absolutely needed for some problem domains. One of the nice things about the Un*x design paradigm is how the goal is consistently been "to make simple things easy, and hard things possible". Unfortunately, in the world of audio APIs, it seems that we've fallen between two stools: we have one API that makes simple things easy, but hard things *impossible*, and another that makes *everything* possible, but also hard. How do we bring these two worlds together? Cheers! |-------------------------------------------------------------------------| | Frederick F. Gleason, Jr. | Chief Developer | | | Paravel Systems | |-------------------------------------------------------------------------| | There are two ways of constructing a software design. One is to make | | it so simple that there are obviously no deficiencies; the other is | | to make it so complicated that there are no obvious deficiencies. | | The first method is far more difficult. | | --C.A.R Hoare | |-------------------------------------------------------------------------|

On Saturday 15 November 2008 09:13:33 pm Jack O'Quin wrote: Or OSS or PortAudio or [insert-favorite-framework-here]. They all have their places. Yes, which is why I think ALSA is most appropriately characterized as a 'HAL' (Hardware Abstraction Layer). Now if we could just get the bits and pieces documented properly... :) Cheers! |-------------------------------------------------------------------------| | Frederick F. Gleason, Jr. | Chief Developer | | | Paravel Systems | |-------------------------------------------------------------------------| | Documentation is like castor oil: managers know it must be good | | because programmers hate writing it so much. | | -- Anonymous | |-------------------------------------------------------------------------|

One question about Hardware Abstraction Layers. My $3 onboard chip variation of Intel HD Audio supports the opening of 5 independent analog stereo out with individual samplerates and switchable line/headphone power levels. It also supports three independent stereo line/instrument/microphone in, with DC power for microphones if needed. There is an onboard patchbay where one can route most anything around in any sick way imaginable ... Not that I would do anything like that :-D, the ins and outs are labeled as such and I do not mind keeping things on an understandable level. Apparently the driver even knows the coloration of individual jacks, which I find as close to magic as to be almost scary ... Anyways, the question is, how do I do the following: Use the three 5.1 stereo jacks out /exclusively/ for my synthesizers. Use one stereo jack for Lo-Fi desktop beeps and other attention grabbers, even various sounds and/or music coming from Mozilla plugins. Use one stereo jack for headphone communication (Ekiga or Skype) as well as a HiFi version of the Mozilla plugins mixed in. ?

On Sat, Nov 15, 2008 at 08:37:58PM -0500, Fred Gleason wrote: And there is such a thing as 'network management'. It's nothing new. It's much worse than that. There are more and more system level modules being designed or written by people who have apparently never seen anything but a single user looking at a desktop, who seem to think that all computers are used like that and that their limited experience should define everybody's limits. The result is desktop-specific configuration being implemented at the wrong place. Just one example: in many systems permissions of the audio devices are set by the desktop login manager. So if you do a remote login to a headless machine you can't use the audio. Now this is completely inconsistent: if any member of the audio group can bring down a machine by running real-time threads and locking unlimited amounts of memory, then there's no problem with giving them access to the devices as well. All you need is an udev rule. Another braindead thing is the 'Destktop Directories'. Even if you don't run a desktop that needs them, some clever bloke wants to impose his childish home directory structure. And it's done in an insane way: some binary called from the X11 startup scripts. And oh yes, in the same way as for spam, you can opt out. But only if you are prepared to leave some junk config files in your home (the sane solution is to remove the packages once and for all). Ciao, -- FA Laboratorio di Acustica ed Elettroacustica Parma, Italia Lascia la spina, cogli la rosa.

On Sunday 16 November 2008 04:16:19 pm you wrote: So this is a reason to cripple the API -- because 'typical' application programmers don't know what they're doing? What about those who *do*? Whatever the semantic difference between 'applications' and 'system tools' might be, *both* end up having to interact with the hardware via some sort of API, so I'm not sure that the distinction is particularly meaningful in this context. Right, but I think you're kind of missing the point. We're not talking about garden variety 'audio player' applications here. The world of audio -- especially professional audio -- is a much larger place. This doesn't make such applications 'system tools', merely applications that work outside of the simple assumptions adequate when designing garden-variety 'audio players'. To hardwire those simple assumptions into the driver system is IMO a design error, one that imposes serious limits on the usefulness of the overall system. Effectively, it's dictating policy in a layer that should be primarily concerned with mechanism. Cheers! |-------------------------------------------------------------------------| | Frederick F. Gleason, Jr. | Chief Developer | | | Paravel Systems | |-------------------------------------------------------------------------| | The real problem with hunting elephants is carrying the decoys. | | -- Anonymous | |-------------------------------------------------------------------------|

Fons Adriaensen wrote: Most of these functions are for accessing structure elements that ALSA doesn't want to expose directly so that the structure layout can change in future library versions. In an API like OSS, the code above would look like this, without separate functions: snd_ctl_elem_value_t value; value.interface = SND_CTL_ELEM_IFACE_MIXER; strcpy(value.name, "Sample Clock Source"); value.enumerated[0] = 3; snd_ctl_elem_info_alloca(&info) snd_ctl_elem_info_set_interface(info, SND_CTL_ELEM_IFACE_MIXER); snd_ctl_elem_info_set_name(info, "Sample Clock Source"); CHECK(snd_ctl_elem_info(ctl, info)); id = snd_ctl_elem_info_get_numid(info); (This is the same id value as shown by alsactl/amixer.) snd_ctl_elem_value_set_numid(value, id); snd_ctl_elem_value_set_enumerated(value, 0, 3); CHECK(snd_ctl_elem_write(ctl, value)); HTH Clemens