From: Jonathan W. <jw...@ph...> - 2011-03-10 23:05:59
|
Combining several posts ... Clemens Ladisch wrote: > From the interface standpoint, the best alternatives would be to have all > the code in the kernel (using the existing ALSA interfaces), or to stay > with the current FFADO, where all the code is in userspace (using the > existing FireWire lowlevel interface). I guess there's really two separate components here which - at least for most devices - are quite separable. The first is the streaming and the control of that. The second is the device control. There's a small amount of overlap for things like sample rate and settings which alter the number of channels. However, by far the largest chunk of the "control" side of things has to do with the control of the onboard mixer which, as was said later, has no impact on the streaming side at all. The picture I had of all this was that the streaming stuff would go into the kernel (perhaps along with the device control which affected streaming, so long as a suitable kernel-userspace interface was available to provide all such controls), with the rest of the device control remaining in userspace. At least for the devices I deal with, this separation generally makes sense; the mixer control doesn't *need* to be in-kernel, it's carried out generally without any need to interact with the streaming layer at all, and would keep a lot of complex code out of the kernel. My interpretation of Linus's post is that the above general idea would be acceptable. What he would object to is if the kernel streaming engine required action on the part of a userspace component simply to work. > > Putting the device initialization-code into kernel-space too will > > result in a major increase in kernelcode > > Which is not a problem. As long as it increases the robustness of the > driver, it's preferrable. Obviously doing so involves more complexity for some devices than others. > Anyway, I think I should report on the current status of kernel > streaming, and where it's going. > : Thanks for this update. > 3) Fireworks (Echo), and > 4) DICE: these drivers are in development. ... > : > I expect to have nailed down the device-specific API of these drivers > shortly. > > As for future drivers: RME and MOTU drivers cannot reuse the AMDTP > code, but should otherwise be similar to the Fireworks/DICE drivers. So I guess the sensible thing for me to do here is to use either the Fireworks or DICE drives as a sort of guide when implementing RME/MOTU support. That sounds fine to me. Do you have any feeling as to when these drivers might be in a condition which gives me a reasonably accurate idea of how things should be structured? Will that be when you merge them to ALSA, or should I grab them earlier? And if the latter, how is this to be done (I presume it's in a git repo somewhere). > Reporting of control changes requires some new API (like the DICE > notifications), but falls under Linus' second point ... Agreed. Clemens Ladisch wrote: > Arnold Krille wrote: > > On Thursday 10 March 2011 13:18:40 Clemens Ladisch wrote: > > > AV/C devices cannot be handled this easily; "user space helps kernel" > > > is exactly what was proposed. I'm wondering if it is possible for the > > > driver to detect (only) the current configuration, and to let userspace > > > notify it when the configuration was changed. > > > > But the kernel will "see" the changes much earlier because the streaming will > > not work correctly. Waiting then for user-space to notify about the changes > > sounds dangerous. > > I mentioned the DICE driver's "lock" ioctl that must be used by > userspace to prevent the driver from streaming while 'dangerous' > configuration changes are being made; the same will be applicable here. Yes. At least for RME/MOTU, a simple lock along these lines should cover all situations I would have to deal with. From: Stefan wrote: > I suppose sync does change indeed. At least the Linux node did not > transmit between PM suspend and resume, and from the driver's POV there > was a jump in bus time and real time. ... Device state could have changed. Yes. But topology could also have changed and this may affect sync for some devices. So really after a suspend things really have to be reinitialised from scratch anyway. > But take for example firewire-sbp2: It assumes that it can simply go on > using any storage device that is still there after resume and accepted the > re-login. If the user or a concurrent SBP-2 initiator modified the > device's store or other state between suspend and resume, he presumably > knew what he was doing. Making an analogy to firewire audio devices, the "re-login" would be equivalent to configuring the device as we want it to be. Firewire audio devices do not generally support anything like SBP-2's concurrent initiators, so that's not really a practical problem. The reason why device configuration could have changed is that quite a few devices have front panel controls which can be used to change device settings, and some devices don't even power up in the same state they were in when powered off. But I don't see any of this being a major problem though - so long as the situation is understood by us we can code accordingly. Although I haven't looked into it in any great detail, I haven't yet seen an incompatibility between this requirement and the API separations being proposed. Regards jonathan |
From: Jonathan W. <jw...@ph...> - 2011-03-21 23:11:19
|
Hi Clemens > > I estimate I'll have something next week, in a git repo. > > Branch firewire-kernel-streaming in <git://git.alsa-project.org/alsa-kprivate.git>. > The driver is incomplete, and the userspace interface in <sound/firewire.h> > is not yet implemented. When do you expect to have at least some embrionic code in place for this. At least for the RME I'm going to need this from a very early stage due to the way those devices work. Then again, I guess it's just a case of configuring a suitable ioctl handler, right? A question: for the RME I am going to need to share configuration status information between userspace and kernelspace. That is, both the kernel driver and the userspace components need to know certain details about the device's status which cannot be read from the device (in essence, everything which manipulates the device's configuration needs access to a central "cache" of the status on the PC). Where do you see such a thing fitting into the userspace interface you've described in sound/firewire.h? I'm thinking that this could perhaps be fetched and set using an RME-specific ioctl. Would that be acceptable do you think? > browsing: <http://git.alsa-project.org/?p=alsa-kprivate.git;a=shortlog;h=firewire-kernel-streaming> > > To download the repository: > > git clone -b firewire-kernel-streaming git://git.alsa-project.org/alsa-kprivate.git firewire-kernel-streaming Thanks for the info. As I understand it, this will drag down an entire kernel tree with history, right? For those of us not currently involved in kernel development this will constitute a *huge* download if I understand things correctly. Unfortunately I'm at the end of a ridiculously slow DSL link at home with a rather low quota, so something like this will be rather problematic. And I guess I'll have to find a significant amount of HDD space too (my drivers are currently rather full). Is there any way to avoid downloading all the extra stuff which is irrelevant to me, or do I have to bite the bullet and accept that a massive download is the only way to get into the development of this driver? Regards jonathan |
From: Stefan R. <st...@s5...> - 2011-03-22 00:38:02
|
On Mar 22 Jonathan Woithe wrote: > > To download the repository: > > > > git clone -b firewire-kernel-streaming git://git.alsa-project.org/alsa-kprivate.git firewire-kernel-streaming > > Thanks for the info. > > As I understand it, this will drag down an entire kernel tree with history, > right? For those of us not currently involved in kernel development this > will constitute a *huge* download if I understand things correctly. > Unfortunately I'm at the end of a ridiculously slow DSL link at home with a > rather low quota, so something like this will be rather problematic. A new "git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git" downloads 402 MB over the net and takes 35 minutes over a 2 Mb/s link. (As soon as you have such a repo locally, other fetches --- or clones with a reference to the first clone for local sharing of objects --- will of course download only a very tiny fraction of that; only the history that you don't have yet.) > And I guess I'll have to find a significant amount of HDD space too (my > drivers are currently rather full). History and checked-out sources take up 940 MB. Half of that is history, the other half checked-out sources. Compiled with a lean configuration --- just the options and drivers that I need myself --- another 500 MB are occupied. (Hmm, quite a lot. The installed kernel image and modules take up 2.5 MB + 22 MB.) -- Stefan Richter -=====-==-== --== =-==- http://arcgraph.de/sr/ |
From: Adrian K. <ad...@dr...> - 2011-03-22 08:36:31
|
On Tue, Mar 22, 2011 at 09:40:56AM +1030, Jonathan Woithe wrote: > > git clone -b firewire-kernel-streaming git://git.alsa-project.org/alsa-kprivate.git firewire-kernel-streaming > > Thanks for the info. > > As I understand it, this will drag down an entire kernel tree with history, > right? For those of us not currently involved in kernel development this > will constitute a *huge* download if I understand things correctly. You could tell git to only download the current revision, thus losing all the history. This has some limitations (see man git-clone), but might be enough to get started: git clone --depth 1 ... Cheers -- mail: ad...@th... http://adi.thur.de PGP/GPG: key via keyserver |
From: Jonathan W. <jw...@ph...> - 2011-03-25 09:47:14
|
> > > git clone -b firewire-kernel-streaming git://git.alsa-project.org/alsa-kprivate.git firewire-kernel-streaming > > > > Thanks for the info. > > > > As I understand it, this will drag down an entire kernel tree with history, > > right? For those of us not currently involved in kernel development this > > will constitute a *huge* download if I understand things correctly. > > You could tell git to only download the current revision, thus losing > all the history. This has some limitations (see man git-clone), but > might be enough to get started: git clone --depth 1 ... That's certainly a partial solution, but its use does potentially create pain for others since you have to rely on others to check your work in manually down the track. Git is a good system, but its strength is also its weakness and this is seen very clearly with a project the size of the kernel. For people who are working on only a tiny portion of the system (which is most people I suspect), a vast majority of the history and the tree holds no interest what-so-ever. Yet in order to be a first-class "git" citizen one has to be prepared to download a huge amount of data initially, and devote a significant amount of HDD space to the storage of data most of which is of no relevance to the area of interest. It's progress, but for some it also presents challenges which other systems such as svn (for all their weaknesses) don't. Regards jonathan |
From: Clemens L. <cl...@la...> - 2011-03-25 10:10:43
|
Jonathan Woithe wrote: > > You could tell git to only download the current revision, thus losing > > all the history. This has some limitations (see man git-clone), but > > might be enough to get started: git clone --depth 1 ... > > That's certainly a partial solution, but its use does potentially create > pain for others since you have to rely on others to check your work in > manually down the track. > > Git is a good system, but its strength is also its weakness and this is seen > very clearly with a project the size of the kernel. For people who are > working on only a tiny portion of the system (which is most people I > suspect), a vast majority of the history and the tree holds no interest > what-so-ever. Yet in order to be a first-class "git" citizen one has to be > prepared to download a huge amount of data initially, and devote a > significant amount of HDD space to the storage of data most of which is of > no relevance to the area of interest. In my kernel tree, the .git directory with the entire history is 583 MB, the checked-out source code alone (without generated files) is 483 MB. > It's progress, but for some it also presents challenges which other systems > such as svn (for all their weaknesses) don't. Typically, a subversion source tree with one checked-out revision uses more disk space than a git tree with its entire history because svn keeps an uncompressed copy of all files around. This overhead is quite unexpected for most people, but is the result of a conscious design decision to make some diffs faster. Regards, Clemens |
From: Jonathan W. <jw...@ph...> - 2011-03-25 11:50:59
|
Clemens wrote: > In my kernel tree, the .git directory with the entire history is 583 MB, > the checked-out source code alone (without generated files) is 483 MB. Ok, that's not as bad as I thought. Still, that's quite a download for someone stuck at the end of a DSL line that's surprisingly slow given that I'm 12 km from the city centre. :-( Thanks for the info. Regards jonathan |
From: Stefan R. <st...@s5...> - 2011-03-25 13:35:02
|
On Mar 25 Jonathan Woithe wrote: > > In my kernel tree, the .git directory with the entire history is 583 MB, > > the checked-out source code alone (without generated files) is 483 MB. > > Ok, that's not as bad as I thought. Still, that's quite a download for > someone stuck at the end of a DSL line that's surprisingly slow given that > I'm 12 km from the city centre. :-( The actual download by a "git clone" of Linus' repo is only 400 MB even. And git shows a nice progress indicator for those who want to verify the golden rule of "a watched download never finishes". Alas there does not seem to be a git.kernel.org frontend server in Australia. For Europeans, *.kernel.org are resolved to *.eu.kernel.org which are located in a European datacenter. git.alsa-project.org seems to be located in Europe too. -- Stefan Richter -=====-==-== --== ==--= http://arcgraph.de/sr/ |
From: Jonathan W. <jw...@ph...> - 2011-03-26 04:24:56
|
Hi Clemens > git clone -b firewire-kernel-streaming git://git.alsa-project.org/alsa-kprivate.git firewire-kernel-streaming Ok, I've grabbed this and have had a cursary look through it to get some idea of how all this fits together. Most of it makes some sort of sense but I have an initial round of questions for you. I apologise that they are probably all rather trivial, but as one who's never gone into these lower layers of ALSA before I'm a little unsure of some of the details. Firstly, of the devices presently in the above tree I think the DICE one is the most appropriate to base my MOTU/RME work off of, so most of these questions relate to it. 1) I notice that the PCM ioctl is just snd_pcm_lib_ioctl at present. I assume that if I need anything beyond what this gives that I'd define a local ioctl hander and use that instead (possibly calling snd_pcm_lib_ioctl() so those base ioctls still work). 2) What exactly is the hwdep stuff? Most of it is still to be implemented so presumedly it's not critical to getting streaming working. 3) The code seems to suggest that DICE operation is limited to 44.1 kHz for now since the rate_* fields are hardcoded to this in dice_open(). Is my reading of this corret? 4) The snd_pcm_ops structure defines a bunch of functions whose purpose I can only roughly deduce. Is there any definitive source which describes what each of these functions is expected to do, especially as this relates to the streaming system? 5) I'm a little unclear as to where the encoding/decoding of firewire packets occurs. There's an amdtp function for this, but how exactly does it get called? Finally, a more generic question. In the ALSA world, is it possible to attach descriptive names to PCM channels so a user has some way of working out what is what (eg: "Analog-1", "Phones-L" - along the lines of jackd's concept of aliases)? Or is it a case that the user just has to know? This is of interest for firewire devices because of the number of channels present and the fact that channels can come and go depending on the device's configuration. If ALSA doesn't have this I guess we (as in ffado) may have to come up with some sort of userspace tool which tells a user what each of their channels are. Thanks for your continued assistance in this. Regards jonathan |
From: Clemens L. <cl...@la...> - 2011-03-28 07:14:02
|
Jonathan Woithe wrote: > Firstly, of the devices presently in the above tree I think the DICE one is > the most appropriate to base my MOTU/RME work off of Yes, but it's also the most incomplete. > 1) I notice that the PCM ioctl is just snd_pcm_lib_ioctl at present. I > assume that if I need anything beyond what this gives that I'd define a > local ioctl hander and use that instead (possibly calling > snd_pcm_lib_ioctl() so those base ioctls still work). This callback is only called by the ALSA framework for some internal things, it's not available from user space. > 2) What exactly is the hwdep stuff? "Hardware dependent"; this is where you add your own ioctls. > 3) The code seems to suggest that DICE operation is limited to 44.1 kHz for > now since the rate_* fields are hardcoded to this in dice_open(). Is my > reading of this corret? Yes. > 4) The snd_pcm_ops structure defines a bunch of functions whose purpose I > can only roughly deduce. Is there any definitive source which describes > what each of these functions is expected to do, especially as this > relates to the streaming system? The only definite source is the source code :-), but docs are available here: <http://www.alsa-project.org/~tiwai/writing-an-alsa-driver/> ("Operators"). > 5) I'm a little unclear as to where the encoding/decoding of firewire > packets occurs. There's an amdtp function for this, but how exactly does > it get called? The ALSA framework was designed on the assumption that the hardware is told the location of the ring buffer and then asynchronously reads from or writes to this buffer by itself. In the case of FireWire, moving samples between the buffer and the controller's queue is done in the packet completion callback. > In the ALSA world, is it possible to attach descriptive names to PCM > channels so a user has some way of working out what is what? Not yet. Regards, Clemens |
From: Jonathan W. <jw...@ph...> - 2011-03-28 11:38:53
|
Hi Clemens Thanks for the info. I'll undoubtedly have further questions later but this gives me a handle on things to start with. A git newbie question to finish off with. How do I import recent changes into my local git repo? I guess I'm after the git equivalent of the subversion "update" command. Would that be "git pull" from the toplevel repo directory? Regards jonathan |
From: Clemens L. <cl...@la...> - 2011-03-28 11:57:14
|
Jonathan Woithe wrote: > A git newbie question to finish off with. How do I import recent changes > into my local git repo? I guess I'm after the git equivalent of the > subversion "update" command. Would that be "git pull" from the toplevel > repo directory? If you are in the correct branch, yes. (If you have made changes, "git pull" will do a merge.) Regards, Clemens |
From: Stefan R. <st...@s5...> - 2011-03-28 12:23:16
|
On Mar 28 Jonathan Woithe wrote: > A git newbie question to finish off with. How do I import recent changes > into my local git repo? I guess I'm after the git equivalent of the > subversion "update" command. Would that be "git pull" from the toplevel > repo directory? Depends on how you created your repository. If you cloned git://git.alsa-project.org/alsa-kprivate.git (as opposed to cloned some other kernel repo and then created an alsa-kprivate.git tracking branch in there), then you have the following: $ cat .git/config [core] repositoryformatversion = 0 filemode = true bare = false logallrefupdates = true [remote "origin"] fetch = +refs/heads/*:refs/remotes/origin/* url = git://git.alsa-project.org/alsa-kprivate.git [branch "firewire-kernel-streaming"] remote = origin merge = refs/heads/firewire-kernel-streaming with one local branch: $ git branch * firewire-kernel-streaming (The asterisk means that this branch is the currently active branch, e.g. has been checked out.) and a few branches of the remote that is called "origin": $ git branch -r origin/HEAD -> origin/master origin/firewire-kernel-streaming origin/fireworks origin/master If you now call "git fetch", updates from alsa-kprivate.git are being downloaded into the remote branches: $ git fetch --verbose From git://git.alsa-project.org/alsa-kprivate = [up to date] firewire-kernel-streaming -> origin/firewire-kernel-streaming = [up to date] fireworks -> origin/fireworks = [up to date] master -> origin/master You can then choose to merge from one of those branches into the currently active branch: $ git merge --verbose origin/firewire-kernel-streaming Already up-to-date. However, one would more typically simply combine "fetch" and "merge" into a single operation, which would be "pull": $ git pull --verbose From git://git.alsa-project.org/alsa-kprivate = [up to date] firewire-kernel-streaming -> origin/firewire-kernel-streaming = [up to date] fireworks -> origin/fireworks = [up to date] master -> origin/master Already up-to-date. In the more general case that one tracks more than one remote repository, one can add git URLs or remote shorthands (like "origin") to git fetch and git pull respectively, to fetch or pull one out of several remote repositories. "git remote ..." can be used to manage shorthands for remote repositories. By the way, here are two things that I use rather frequently, instead of memorizing things: $ git whatever --help # same as "man git-whatever" $ gitk [branch name or source directory or tag name...] # What's in here? -- Stefan Richter -=====-==-== --== ===-- http://arcgraph.de/sr/ |
From: Clemens L. <cl...@la...> - 2011-03-22 12:53:17
|
Jonathan Woithe wrote: > > The driver is incomplete, and the userspace interface in <sound/firewire.h> > > is not yet implemented. > > When do you expect to have at least some embrionic code in place for this. Soon. > Then again, I guess it's just a case of configuring a suitable ioctl > handler, right? Yes. > A question: for the RME I am going to need to share configuration status > information between userspace and kernelspace. That is, both the kernel > driver and the userspace components need to know certain details about the > device's status which cannot be read from the device (in essence, everything > which manipulates the device's configuration needs access to a central > "cache" of the status on the PC). Where do you see such a thing fitting > into the userspace interface you've described in sound/firewire.h? One requirement that I try to implement is that any driver has to work even without the userspace component, using the current or default settings. This implies that the authoritative copy of these settings is in the driver. > I'm thinking that this could perhaps be fetched and set using an RME- > specific ioctl. Would that be acceptable do you think? Yes; I don't see any sane but different way to implement this. As far as I can tell from your RME notes, the number of channels is fixed per model, and the devices cannot synchronize to the computer's playback stream, so the only such setting would be the nominal sample rate. Regards, Clemens |
From: Jonathan W. <jw...@ph...> - 2011-03-22 22:38:58
|
Hi Clemens > > A question: for the RME I am going to need to share configuration status > > information between userspace and kernelspace. That is, both the kernel > > driver and the userspace components need to know certain details about the > > device's status which cannot be read from the device (in essence, everything > > which manipulates the device's configuration needs access to a central > > "cache" of the status on the PC). Where do you see such a thing fitting > > into the userspace interface you've described in sound/firewire.h? > > One requirement that I try to implement is that any driver has to work > even without the userspace component, using the current or default > settings. This implies that the authoritative copy of these settings > is in the driver. Indeed - that was exactly how I saw things working in this respect. > > I'm thinking that this could perhaps be fetched and set using an RME- > > specific ioctl. Would that be acceptable do you think? > > Yes; I don't see any sane but different way to implement this. Awesome - thanks. > As far as I can tell from your RME notes, the number of channels is > fixed per model, and the devices cannot synchronize to the computer's > playback stream, so the only such setting would be the nominal sample > rate. Not exactly (I need to update my notes to clarify a few things). The number of channels is variable because you can turn off particular groups of channels if you're not interested in using them. In RME-speak this goes by the name of (firewire) bandwidth limiting. So for instance you can request that only analog and SPDIF channels are sent - this means ADAT channels are neither sent nor expected by the interface. So at the very least this "bandwidth limit" setting would also need to be included. It's true that the devices don't synchronise to the playback stream in the same way that other firewire devices do. They do synchronised in their own special way though. The big issue with the RME is that it is in fact impossible to configure most device settings separately - a vast majority of the device configuration settings can only be sent as a complete block (sample rate and stream enabling are separate, but interestingly enough clock source is not). Furthermore, the device itself does not provide any method for the computer to query the current device settings which means the computer needs to cache this so it's available when needed. I could therefore make an argument that the kernel driver should in fact be the authoritative source of this information so the current device configuration remains available for the lifetime of the driver - even through the kernel driver itself won't directly use most of it. Otherwise arrangements would be needed for usespace tools to write the configuration out to a file somewhere whenever they change it, and this seems potentially messy to me. A further issue is that the kernel driver will need to write a known baseline configuration to the device anyway because this is needed before streaming can be started (until this is done the device remains in "standalone" mode). I'll see how things pan out though. Regards jonathan |
From: Clemens L. <cl...@la...> - 2011-03-11 08:38:23
|
Jonathan Woithe wrote: > Clemens Ladisch wrote: > > As for future drivers: RME and MOTU drivers cannot reuse the AMDTP > > code, but should otherwise be similar to the Fireworks/DICE drivers. > > So I guess the sensible thing for me to do here is to use either the > Fireworks or DICE drives as a sort of guide when implementing RME/MOTU > support. That sounds fine to me. Do you have any feeling as to when these > drivers might be in a condition which gives me a reasonably accurate idea of > how things should be structured? I estimate I'll have something next week, in a git repo. Regards, Clemens |
From: Clemens L. <cl...@la...> - 2011-03-17 08:29:07
|
I wrote: > Jonathan Woithe wrote: > > Clemens Ladisch wrote: > > > As for future drivers: RME and MOTU drivers cannot reuse the AMDTP > > > code, but should otherwise be similar to the Fireworks/DICE drivers. > > > > So I guess the sensible thing for me to do here is to use either the > > Fireworks or DICE drives as a sort of guide when implementing RME/MOTU > > support. That sounds fine to me. Do you have any feeling as to when these > > drivers might be in a condition which gives me a reasonably accurate idea of > > how things should be structured? > > I estimate I'll have something next week, in a git repo. Branch firewire-kernel-streaming in <git://git.alsa-project.org/alsa-kprivate.git>. The driver is incomplete, and the userspace interface in <sound/firewire.h> is not yet implemented. browsing: <http://git.alsa-project.org/?p=alsa-kprivate.git;a=shortlog;h=firewire-kernel-streaming> To download the repository: git clone -b firewire-kernel-streaming git://git.alsa-project.org/alsa-kprivate.git firewire-kernel-streaming To avoid downloading the entire kernel history, you can reuse the data from an existing kernel repository: git clone -b firewire-kernel-streaming --reference /path/to/kernel/repository git://git.alsa-project.org/alsa-kprivate.git firewire-kernel-streaming To download as a new branch in an existing repository: git fetch git://git.alsa-project.org/alsa-kprivate.git firewire-kernel-streaming:firewire-kernel-streaming Regards, Clemens |
From: Stefan R. <st...@s5...> - 2011-03-20 18:53:26
|
Signed-off-by: Stefan Richter <st...@s5...> --- sound/firewire/Kconfig | 1 + 1 file changed, 1 insertion(+) Index: b/sound/firewire/Kconfig =================================================================== --- a/sound/firewire/Kconfig +++ b/sound/firewire/Kconfig @@ -14,6 +14,7 @@ config SND_FIREWIRE_LIB config SND_DICE tristate "DICE devices (EXPERIMENTAL)" depends on EXPERIMENTAL + select SND_HWDEP select SND_PCM select SND_FIREWIRE_LIB help -- Stefan Richter -=====-==-== --== =-=-- http://arcgraph.de/sr/ |
From: Clemens L. <cl...@la...> - 2011-03-21 12:43:39
|
Stefan Richter wrote: > + select SND_HWDEP Applied; thanks. Clemens |
From: Clemens L. <cl...@la...> - 2011-03-21 12:40:46
|
Pieter Palmers wrote: > I will try to cook up something for the bebob devices based upon your > snd-speaker driver, but that's more as an exercise. That driver, by itself, is not a good example for devices that FFADO cares about because it doesn't support capturing or different clock sources. I decided that for 'plug-and-play' consumer devices, a self- contained driver without any user space components would be more reliable. This driver avoids doing complicated discovery only by hardcoding many things. > How does the fireworks driver you already have fit in btw? Much of its code (AMDTP, CMP etc.) ended up in snd-firewire-lib.ko. Handling of mixer controls and most other device-specific commands will move to user space; there will be a new snd-fireworks driver with the same structure as the DICE driver, i.e., very small. > I assume that you're already working on bi-directional streaming, so I'm > going to keep my hands off that. [...] > I think the most apparent candidate to work on would be a first > prototype of a userspace API to couple the drivers to the current FFADO > discovery code. See <include/sound/firewire.h>. It's not yet implemented; the "configuration lock" ties into sample rate changes which I'm doing right now; capturing is next. > Would the userspace component use the firewire API or would it go > through the ALSA driver for its communication with the device? Some things like DICE notifications or non-FCP Echo commands must be implemented by the driver because the FireWire core does not allow sharing address ranges (except FCP); these will get a new API. All other FireWire accesses can be done with the existing API. > I assume it's not the intention that the kernel driver responds to ALSA > samplerate change API requests? Indeed; with all streams using the same master sample rate, and with MIDI accesses potentially having to start streaming before a PCM is opened, it's not possible to offer applications a choice. Either the driver implements a "Sample Rate" mixer control, or user space does and the driver simply reads the device's current configuration when needed. Regards, Clemens |
From: Clemens L. <cl...@la...> - 2011-04-29 08:00:16
|
Hi, to demonstrate how the userspace API might be used, I've written a small DICE control panel: http://www.alsa-project.org/~clemens/not-the-dice-control-panel.c Except for the driver API itself, this program should not be taken too seriously (it works, though). Regards, Clemens |
From: Stefan R. <st...@s5...> - 2011-03-30 22:26:42
|
Hi, two things about <sound/firewire.h>: - Somebody just registered a 'H' F1 ioctl number in Documentation/ioctl/ioctl-number.txt. - The structs for read() and ioctl() operations contain unsigned int at the moment. 64 bit kernels will therefore have to have compat handlers to support 32 bit userland. This can --- and to my understanding should --- be avoided by only using types whose size and alignment are the same on 32 bit and 64 bit variants of an architecture. -- Stefan Richter -=====-==-== --== ===== http://arcgraph.de/sr/ |
From: Stefan R. <st...@s5...> - 2011-03-30 22:43:31
|
On Mar 31 Stefan Richter wrote: > - Somebody just registered a 'H' F1 ioctl number in > Documentation/ioctl/ioctl-number.txt. > > - The structs for read() and ioctl() operations contain unsigned int at > the moment. 64 bit kernels will therefore have to have compat > handlers to support 32 bit userland. This can --- and to my > understanding should --- be avoided by only using types whose size and > alignment are the same on 32 bit and 64 bit variants of an > architecture. (Same alignment of struct members, not of the types, to be super precise.) -- Stefan Richter -=====-==-== --== ===== http://arcgraph.de/sr/ |
From: Pieter P. <pi...@jo...> - 2011-03-19 10:28:01
|
On 03/17/2011 09:30 AM, Clemens Ladisch wrote: > I wrote: >> Jonathan Woithe wrote: >>> Clemens Ladisch wrote: >>>> As for future drivers: RME and MOTU drivers cannot reuse the AMDTP >>>> code, but should otherwise be similar to the Fireworks/DICE drivers. >>> >>> So I guess the sensible thing for me to do here is to use either the >>> Fireworks or DICE drives as a sort of guide when implementing RME/MOTU >>> support. That sounds fine to me. Do you have any feeling as to when these >>> drivers might be in a condition which gives me a reasonably accurate idea of >>> how things should be structured? >> >> I estimate I'll have something next week, in a git repo. > > Branch firewire-kernel-streaming in<git://git.alsa-project.org/alsa-kprivate.git>. > The driver is incomplete, and the userspace interface in<sound/firewire.h> > is not yet implemented. > I've tried the dice driver and am happy that it works with the saffire pro40 ;). I have some time during the next weeks. For what parts would you like some help? I assume that you're already working on bi-directional streaming, so I'm going to keep my hands off that. I will try to cook up something for the bebob devices based upon your snd-speaker driver, but that's more as an exercise. How does the fireworks driver you already have fit in btw? I think the most apparent candidate to work on would be a first prototype of a userspace API to couple the drivers to the current FFADO discovery code. Do you have a specific strategy in mind for the userspace component? What would you keep in userspace and what in kernelspace? Would the userspace component use the firewire API or would it go through the ALSA driver for its communication with the device? I assume it's not the intention that the kernel driver responds to ALSA samplerate change API requests? AFAICT that requires some kernel=>userspace=>kernel notification/action mechanism, which doesn't feel like a good idea. Regards, Pieter |
From: Stefan R. <st...@s5...> - 2011-03-20 20:22:06
|
On Mar 19 Pieter Palmers wrote: > On 03/17/2011 09:30 AM, Clemens Ladisch wrote: > > Branch firewire-kernel-streaming in<git://git.alsa-project.org/alsa-kprivate.git>. > > The driver is incomplete, and the userspace interface in<sound/firewire.h> > > is not yet implemented. > > > > I've tried the dice driver and am happy that it works with the saffire > pro40 ;). Playback with Saffire PRO 24 works here as well (after altering the specifier ID in dice_id_table to 0x130e in order to get the driver bound). "arecord -l" comes up empty. -- Stefan Richter -=====-==-== --== =-=-- http://arcgraph.de/sr/ |