From: FFADO <ffa...@ff...> - 2010-02-10 07:06:51
|
#265: can't find "Enable Pedal" footswitch (punch) setting on ffado-mixer for MOTU 896HD -------------------------------------------------+-------------------------- Reporter: sireasoning | Owner: arnonym Type: feature | Status: new Priority: major | Milestone: Component: ffado-mixer | Version: FFADO 2.0.0 Keywords: enable pedal footswitch punch 896HD | Device_name: -------------------------------------------------+-------------------------- I can't seem to find the "Enable Pedal" section on the ffado-mixer on the MOTU 896HD. This is the section where a footpedal or switch can be activated for recording. You would also be able to define what keystrokes would be activated by the footswitch. -- Ticket URL: <http://subversion.ffado.org/ticket/265> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |
From: FFADO <ffa...@ff...> - 2010-02-10 07:11:09
|
#265: can't find "Enable Pedal" footswitch (punch) setting on ffado-mixer for MOTU 896HD ---------------------------+------------------------------------------------ Reporter: sireasoning | Owner: arnonym Type: feature | Status: new Priority: major | Milestone: Component: ffado-mixer | Version: FFADO 2.0.0 Resolution: | Keywords: enable pedal footswitch punch 896HD Device_name: | ---------------------------+------------------------------------------------ Changes (by sireasoning): * cc: jwoithe (added) -- Ticket URL: <http://subversion.ffado.org/ticket/265#comment:1> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |
From: FFADO <ffa...@ff...> - 2010-02-10 22:45:51
|
#265: can't find "Enable Pedal" footswitch (punch) setting on ffado-mixer for MOTU 896HD ---------------------------+------------------------------------------------ Reporter: sireasoning | Owner: jwoithe Type: feature | Status: new Priority: major | Milestone: FFADO 2.x Component: ffado-mixer | Version: FFADO 2.0.0 Resolution: | Keywords: enable pedal footswitch punch 896HD Device_name: MOTU 896HD | ---------------------------+------------------------------------------------ Changes (by jwoithe): * owner: arnonym => jwoithe * milestone: => FFADO 2.x * device_name: => MOTU 896HD Comment: I have not heard of this 896HD feature until now, presumedly because you are the first person with a 896HD and a suitable footswitch to try FFADO. Consequently such a section will not be found in ffado-mixer. To start with, could you describe what functions this footswitch can have? It presumedly connects to a dedicated input on the 896HD and causes some form of signal to be sent back to the PC (which is then used to trigger whatever events the user has configured, such as "record start" and so forth). Assuming this to be broadly correct we will need two components to make this function under FFADO. Firstly we need to add support to the FFADO MOTU driver to detect the signal triggered by the footswitch. Adding support for this will be a little tricky unless you are willing to do some legwork since I do not own an 896HD nor do I have physical access to an 896HD. In short, I need to know out how the footswitch action is transmitted to the PC. Once I know that I can integrate this into FFADO. If you are willing to go digging for this for me please contact me off-list and we'll talk through the various options. Secondly, once FFADO knows how to receive the pedal events it needs some way to communicate the configured action to whatever software it is that you are running. This ''may'' prove to be the more involved process since at present AFAIK FFADO does not have any mechanism we could use for this which would be immediately accessible to other applications (that is, requiring no changes to the applications). I will ponder this side of the equation and in the meantime others may chime in with suggestions. Technically there is a third component - that of configuring the actions to trigger. Until the details of the first two points are clearer it's not possible to work out where this might reside. I have a suspicion that it might not end up being in ffado-mixer due to the complete separation of ffado-mixer from the streaming system. Since the footswitch signals will almost certainly be transmitted in a subchannel of the main data stream this becomes an issue. It's not worth worrying about this though until the previous issues are sorted. -- Ticket URL: <http://subversion.ffado.org/ticket/265#comment:2> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |
From: Stefan R. <st...@s5...> - 2010-02-11 08:58:48
|
FFADO wrote: [Ticket URL: <http://subversion.ffado.org/ticket/265#comment:2>] ... > Firstly we need to add support to the FFADO MOTU driver to detect the > signal triggered by the footswitch. Adding support for this will be a > little tricky unless you are willing to do some legwork since I do not own > an 896HD nor do I have physical access to an 896HD. In short, I need to > know out how the footswitch action is transmitted to the PC. For what it's worth, so far I heard of two types of FireWire input devices: - SBP-2 disk enclosures with a push button. I have no idea how they transport input events. - FireDTV DVB set top boxes with an infraread remote control. They have an extra AV/C subunit (in addition to their tuner subunit) which sends key press events by means of FCP Interim responses to a vendor-specific FCP Notify request. These responses contain the scancode of a pressed key. Of course both methods are specific to these two device types, and MOTUs will almost certainly use an entirely different transport method. ... > Secondly, once FFADO knows how to receive the pedal events it needs some > way to communicate the configured action to whatever software it is that > you are running. It is possible to implement input drivers in userspace. Those are basically loopback drivers which feed input events into the kernel's input subsystem. (Or you communicate directly with an application program e.g. via dbus, of course.) -- Stefan Richter -=====-==-=- --=- -=-== http://arcgraph.de/sr/ |
From: FFADO <ffa...@ff...> - 2010-02-11 03:43:36
|
#265: can't find "Enable Pedal" footswitch (punch) setting on ffado-mixer for MOTU 896HD ---------------------------+------------------------------------------------ Reporter: sireasoning | Owner: jwoithe Type: feature | Status: new Priority: major | Milestone: FFADO 2.x Component: ffado-mixer | Version: FFADO 2.0.0 Resolution: | Keywords: enable pedal footswitch punch 896HD Device_name: MOTU 896HD | ---------------------------+------------------------------------------------ Comment (by sireasoning): It appears to be a simple setup They have just three options: a checkbox for "enable Pedal" Then a place to set the keystroke associated with "Pedal Down" and a keystroke to associate with "Pedal Up" The default is for their software and "Pedal Down" is set to "3" and "pedal Up" is set to "none" If it is as simple as it looks, it would appear that all you need to know is the keystroke. How do I contact you off list? -- Ticket URL: <http://subversion.ffado.org/ticket/265#comment:3> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |
From: FFADO <ffa...@ff...> - 2010-02-11 03:57:35
|
#265: can't find "Enable Pedal" footswitch (punch) setting on ffado-mixer for MOTU 896HD ---------------------------+------------------------------------------------ Reporter: sireasoning | Owner: jwoithe Type: feature | Status: new Priority: major | Milestone: FFADO 2.x Component: ffado-mixer | Version: FFADO 2.0.0 Resolution: | Keywords: enable pedal footswitch punch 896HD Device_name: MOTU 896HD | ---------------------------+------------------------------------------------ Comment (by jwoithe): Thanks for the additional information. From what you describe, it seems that the MOTU does just sent two events: pedal down and pedal up. These are then translated into keystrokes on the PC. So the first part of the task is to work out how the MOTU indicates to the PC that the pedal has gone done and come up. Contacting me off-list: a good question. Perhaps go to my homepage at http://www.physics.adelaide.edu.au/~jwoithe/ You'll find a link to my email address right at the very bottom. If there's a problem let me know. -- Ticket URL: <http://subversion.ffado.org/ticket/265#comment:4> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |
From: FFADO <ffa...@ff...> - 2010-02-11 04:40:51
|
#265: can't find "Enable Pedal" footswitch (punch) setting on ffado-mixer for MOTU 896HD ---------------------------+------------------------------------------------ Reporter: sireasoning | Owner: jwoithe Type: feature | Status: new Priority: major | Milestone: FFADO 2.x Component: ffado-mixer | Version: FFADO 2.0.0 Resolution: | Keywords: enable pedal footswitch punch 896HD Device_name: MOTU 896HD | ---------------------------+------------------------------------------------ Comment (by sireasoning): I sent an email, let me know if you got it.... -- Ticket URL: <http://subversion.ffado.org/ticket/265#comment:5> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |
From: FFADO <ffa...@ff...> - 2010-02-11 05:06:22
|
#265: can't find "Enable Pedal" footswitch (punch) setting on ffado-mixer for MOTU 896HD ---------------------------+------------------------------------------------ Reporter: sireasoning | Owner: jwoithe Type: feature | Status: new Priority: major | Milestone: FFADO 2.x Component: ffado-mixer | Version: FFADO 2.0.0 Resolution: | Keywords: enable pedal footswitch punch 896HD Device_name: MOTU 896HD | ---------------------------+------------------------------------------------ Comment (by jwoithe): Got it - thanks. Will follow up privately and post back here when relevant. -- Ticket URL: <http://subversion.ffado.org/ticket/265#comment:6> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |
From: FFADO <ffa...@ff...> - 2012-03-27 14:56:49
|
#265: can't find "Enable Pedal" footswitch (punch) setting on ffado-mixer for MOTU 896HD ---------------------------+------------------------------------------------ Reporter: sireasoning | Owner: jwoithe Type: feature | Status: new Priority: major | Milestone: FFADO 2.x Component: ffado-mixer | Version: FFADO 2.0.0 Resolution: | Keywords: enable pedal footswitch punch 896HD Device_name: MOTU 896HD | ---------------------------+------------------------------------------------ Comment (by jwoithe): Thanks to a loan 896HD a year or so ago, I now know how the footswitch signal is sent to the PC. There things have rested, mostly because I forgot all about it. I will take another look at this and see if it's possible to easily set up a receiver for these events within the context of FFADO. I suspect a standalone receiving application will be the go, but we'll see. -- Ticket URL: <http://subversion.ffado.org/ticket/265#comment:7> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |
From: FFADO <ffa...@ff...> - 2012-03-31 06:26:22
|
#265: can't find "Enable Pedal" footswitch (punch) setting on ffado-mixer for MOTU 896HD ---------------------------+------------------------------------------------ Reporter: sireasoning | Owner: jwoithe Type: feature | Status: new Priority: major | Milestone: FFADO 2.x Component: ffado-mixer | Version: FFADO 2.0.0 Resolution: | Keywords: enable pedal footswitch punch 896HD Device_name: MOTU 896HD | ---------------------------+------------------------------------------------ Comment (by sireasoning): cool -- Ticket URL: <http://subversion.ffado.org/index.fcgi/ticket/265#comment:8> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |
From: Yves G. <yve...@nu...> - 2012-03-31 09:21:21
|
Hello! I just compiled revision 2102 and I got these warnings: src/dice/dice_eap.cpp: In member function ‘virtual void Dice::EAP::Router::show()’: src/dice/dice_eap.cpp:1613: warning: format ‘%ld’ expects type ‘long int’, but argument 7 has type ‘size_t’ src/dice/dice_eap.cpp:1618: warning: format ‘%ld’ expects type ‘long int’, but argument 7 has type ‘size_t’ src/dice/dice_eap.cpp: In member function ‘void Dice::EAP::RouterConfig::show()’: src/dice/dice_eap.cpp:1801: warning: format ‘%ld’ expects type ‘long int’, but argument 7 has type ‘size_t’ These are just warnings, without impact, but a simple cast could fix it. Regards Yves Grenier |
From: Yves G. <yve...@nu...> - 2012-03-31 09:46:36
|
Hello! I just compiled revision 2102 and jack cannot load driver: JACK compiled with System V SHM support. 11:27:47.185 JACK a été démarrer avec le PID=5852. loading driver .. firewire ERR: Incompatible libffado version! (libffado 2.999.0-2102M) cannot load driver module firewire Regards Yves |
From: Adrian K. <ad...@dr...> - 2012-03-31 09:50:13
|
On 03/31/2012 11:46 AM, Yves Grenier wrote: > Hello! Hi! > I just compiled revision 2102 and jack cannot load driver: > > JACK compiled with System V SHM support. > 11:27:47.185 JACK a été démarrer avec le PID=5852. > loading driver .. > firewire ERR: Incompatible libffado version! (libffado 2.999.0-2102M) > cannot load driver module firewire Exactly as expected. You have to recompile jack, we've bumped the API version. Cheers |
From: Yves G. <yve...@nu...> - 2012-03-31 10:31:02
|
Le 31/03/2012 11:50, Adrian Knoth a écrit : > On 03/31/2012 11:46 AM, Yves Grenier wrote: > >> Hello! > Hi! > >> I just compiled revision 2102 and jack cannot load driver: >> >> JACK compiled with System V SHM support. >> 11:27:47.185 JACK a été démarrer avec le PID=5852. >> loading driver .. >> firewire ERR: Incompatible libffado version! (libffado 2.999.0-2102M) >> cannot load driver module firewire > Exactly as expected. You have to recompile jack, we've bumped the API > version. Thanks for the answer. I was hesitating to recompile jack, in fear that it would create another error! I'll do it now. Regards Yves |
From: Adrian K. <ad...@dr...> - 2012-04-03 08:48:41
|
On Tue, Apr 03, 2012 at 10:38:34AM +0930, Jonathan Woithe wrote: Hi! > > I ask for "true", but since there's still the Exit(1) statement, it > > decides to abort. If I say "true", I want "true", not "educate me about > > what I'm doing". > > Ok, we'll have to agree to disagree here. We have a different understanding of what "true" means. I've now reverted the commit and introduced a new "force" option, so we have: * false: use API_VER 8 * auto: use API_VER 8 or 9 depending on the installed jackd version or API_VER 9 if no jackd is installed * true: use API_VER 9, but abort if detected jackd is too old * force: use API_VER 9 I still don't see why a user would ever want to use this flag at all, since the default (auto) does exactly what he needs. Maybe somebody who's desperately looking for setbufsize support but fails to understand that he has to update jackd. Fingers crossed he doesn't choose "force" in the first place. ;) Anyway, I guess we've done enough now to address the occasional ignorant out there. Universe will prove us wrong, but at least we tried. ;) Cheers -- mail: ad...@th... http://adi.thur.de PGP/GPG: key via keyserver |
From: Jonathan W. <jw...@ju...> - 2012-04-03 12:27:05
|
Hi Adrian On Tue, Apr 03, 2012 at 10:48:25AM +0200, Adrian Knoth wrote: > On Tue, Apr 03, 2012 at 10:38:34AM +0930, Jonathan Woithe wrote: > > > > I ask for "true", but since there's still the Exit(1) statement, it > > > decides to abort. If I say "true", I want "true", not "educate me about > > > what I'm doing". > > > > Ok, we'll have to agree to disagree here. > > We have a different understanding of what "true" means. Yes, at least in this context. :-) > I've now reverted the commit and introduced a new "force" option, so we > have: > > * false: use API_VER 8 > * auto: use API_VER 8 or 9 depending on the installed jackd > version or API_VER 9 if no jackd is installed > * true: use API_VER 9, but abort if detected jackd is too old > * force: use API_VER 9 Ok, that seems fair and closer to what I envisaged. I should note in passing that compiling FFADO for API_VER 8 ("false" setting) and using it against a new jack will actually work - which is why no major warning is flagged in that case. The only truly broken situation is a setting of "true" when the jackd used with the resulting FFADO is old, which is why I felt the error and abort was the right approach. For those like yourself with unusual setups, we have "force". > I still don't see why a user would ever want to use this flag at all, > since the default (auto) does exactly what he needs. Maybe somebody > who's desperately looking for setbufsize support but fails to understand > that he has to update jackd. Yes, probably something like that. I agree that in an ideal world the "auto" setting should do the right thing in almost every case, but there are always corner cases for which it may trip up - which is why this was implemented as an scons option. > Fingers crossed he doesn't choose "force" in the first place. ;) Well, if they do then they've only got themselves to blame. Calling the new option "force" is a pretty strong suggestion that you should know what you're doing. :-) > Anyway, I guess we've done enough now to address the occasional ignorant > out there. Universe will prove us wrong, but at least we tried. ;) Correct. The main thing from my POV was that we have something which makes it easier for end users to test ongoing trunk snapshots without introducing the complication of a jack upgrade in this interim period before the distributions pick up the new jack. Especially since most users don't really care for the setbufsize functionality. I think we've now got a reasonable solution, with the option to override when it turns out to be needed. Thanks for this latest revision. Regards jonathan |
From: Jonathan W. <jw...@ju...> - 2012-04-03 01:08:59
|
Hi Adrian > >[Note that the subject of this thread is wrong: it should refer to r2104, > >not 2014] > : > >Please let me know if my assumptions are incorrect; at the end of the day I > >don't want to make things harder for package maintainers. > > I hate to look like a jerk, but it's still getting on my nerves. ;) > > adi@foh:/opt/adi-src/ffado/libffado$ scons > ENABLE_SETBUFFERSIZE_API_VER=true SHAREDIR=/usr/share/libffado2/ > DEBUG=true -j8 > scons: Reading SConscript files ... > Checking for a working C-compiler (cached) yes > Checking for a working C++-compiler (cached) yes > Checking for pkg-config (at least version 0.0.0)... (cached) yes > Checking for jack >= 0.0.0... (cached) yes > Checking for jack < 1.9.0... (cached) yes > Checking for jack >= 0.122.0... (cached) no > Checking for jack >= 1.9.9... (cached) no > > SetBufferSize API version is enabled but no suitable version of jack > has been found. ... > > I ask for "true", but since there's still the Exit(1) statement, it > decides to abort. If I say "true", I want "true", not "educate me about > what I'm doing". Ok, we'll have to agree to disagree here. The problem I see is that if a user goes "true" but they have the wrong jack version[1] then things will compile but the above note will be lost in a sea of compilation messages. They'll never notice it and then wonder why they still get the error. But whatever, life's too short to argue about this. [1] Yes, this is against all the recommendations, but I guarantee it'll happen. > Scenario: I have an old system-wide jackd installation without bufsize > support, but I compile git jackd versions for testing purpose that > go to /tmp/jack1test or /tmp/jack2test. I heavily use LD_LIBRARY_PATH > all the time to override the stable system installation with my > development versions of jackd and ffado. Admittedly that's hardly representative of a system that'll be encountered in the wider world. I would rather have introduced an additional option to cater for this corner case (basically one which meant "true, I know what I'm doing so please ignore the jack versioning). Anyway, it's done now and I can't be bothered arguing. BTW, good catch with the port cache. I never realised AMDTP maintained an additional layer of caching there. Thanks for chasing that down. Regards jonathan |
From: Yves G. <yve...@nu...> - 2012-04-12 17:56:35
|
Le 12/04/2012 01:42, Jonathan Woithe a écrit : > On Wed, Apr 11, 2012 at 07:46:32PM +0200, Yves Grenier wrote: >>>>>>> I observe that if I try to change the frequency from ffado-mixer, it >>>>>>> creates a failure message, and after acknowledging the message, the >>>>>>> correct sampling frequency is shown in ffado-mixer. >>>>>> Is this with or without jackd running? >>>>>> >>>>> This is with jackd running. It gives me the impression that ffado-mixer >>>>> is able to read the correct sampling frequency once it is instructed to >>>>> do it. > A slightly delayed response to this: I suspect that ffado-mixer is not > re-reading the sample rate. Instead, I think that the GUI control is just > setting itself to whatever was "set" even though an error was flagged. I'll > see if I can work out a way of testing this theory myself. > >>>> This is the correct behaviour since ffado (libffado) prevents any >>>> samplerate change while streaming (jackd running). >>>> jackd must be stopped before any samplerate change. >>> I agree - ffado-mixer should lock the sample rate control once streaming has >>> been started by jackd. However, Yves's report seems to indicate that he was >>> still able to change the sample rate in ffado-mixer when jackd was running. >>> That sounds contrary to the intention. >> This is not what I was meaning. Let me try to explain it in a better >> way. I first start ffado-mixer, and fix the sampling rate with >> ffado-mixer. I then start jackd with another sampling rate. This is >> now the new sampling rate used by the Pro24. Up to now everything >> works, except that ffado-mixer still displays its (wrong) sampling >> frequency. This is the first part of the test. > Ok, that all sounds like it's behaving as we currently expect it to. > >>> Yves, can you confirm that ffado-mixer's sample rate control remains active >>> when jackd is running? >> Now the second part. I do not confirm that the control is active >> when jackd is running: if I try to change the sample rate through >> ffado-mixer, it gives an error message like "Could not select 96000 >> as samplerate" and this is the expected behavior. > By "active" I meant that the GUI widget was not disabled. The fact that you > were able to interact with ffado-mixer's sample rate control while streaming > is active is a bug - it should be greyed out as soon as jackd starts > streaming. At least I *think* that's the case - again, I'll have to check > this. > >> However, when I close the pop-up with this error message, I see that >> ffado-mixer now displays the correct frequency, i.e. the frequency set by >> jackd when it started, not the frequency set by ffado-mixer before jackd >> was started. > Could you try another simple test: > - start ffado-mixer > - start jackd at a rate different to that displayed by ffado-mixer > - try to change the sample rate in ffado-mixer to something different to > that used by jackd. > > I suspect that after dismissing the error dialog, ffado-mixer will just > display the sample rate you selected, which obviously is not the sample rate > in use by jackd. Irrespective of whether this suspicion is correct, it will > tell us quite a bit about what's going on here. Hi, This is the result of the test: 1) I start ffado-mixer and select 96000 Hz. 2) I open jackd, select 41000 Hz and start jackd 3) I try to select 48000 Hz with ffado-mixer while jackd is runing 4) while the error popup is displayed, the sampling rate shown by ffado-mixer is 48000 Hz 5) when I close the popup, ffado-mixer shows a sampling rate of 41000 Hz. > Can you also tell me if the "streaming status" in ffado-mixer changes when > jackd starts? The two buttons under "streaming status" are dimmed when I start ffado-mixer, and they remain dimmed when I start jackd. Regards Yves >> I hope that I am clear now. The point was not on the possibility to >> change the sampling frequency by ffado-mixer when jackd is running, >> but it was on the possibility to display in ffado-mixer the correct >> frequency as set by jackd. > I understand your point of view now. However, this really does comprise two > separate issues. The first is that for the Pro24 at least, ffado-mixer does > not seem to be recognising when streaming starts - it should, and when it > does certain controls (like sample rate selection) should be disabled to > prevent any user interaction with them. In other words, there seems to be a > bug related to the streaming status communicated back to ffado-mixer by > Pro24 interfaces (and probably other Saffires as well) and this needs to be > fixed. > > I've just had a quick look at the dice code (which is what the Pro24 uses I > think) and I note that it does not define its own > Device::getStreamingState() method. This means it relies on the inherited > FFADODevice::getStreamingState() method. Since this method is based on the > standard IEC plug structure it's probably no surprise that it doesn't work > for DICE devices. So the way to fix this particular issue is to work out a > way the DICE driver can use to determine the streaming state and code this > in a custom getStreamingState() method (which is what I do for the MOTU and > RME drivers). Once this method works correctly it should permit the > streaming status to be displayed in ffado-mixer correctly (I'm fairly sure > this automatically updates), and a consequence of this is that the sample > rate control will be disabled (preventing user interaction with it). > > The second part is the question of getting ffado-mixer to update itself if > jackd is started and the sample-rate changes. This can probably be rolled > into the code which handles a change in the streaming status (which > obviously requires that the streaming status be properly communicated to > ffado-mixer first). This is in polledUpdate(), found in > support/mixer-qt4/ffado/mixer/globalmixer.py. I would think that the > streaming status could be cached in a local; then when a change in the > streaming status is detected one could retrieve the current sample rate and > set the samplerate control to that rate. This way the sample rate control > will be disabled for user interaction but will still display the correct > sample rate. > > I might have a go at this tonight if I have time. > > Of course for mixers which require adjustments to the controls offered in > response to a sample rate change this won't be sufficient; ultimately we'd > need some some sort of "sample rate changed" handler to handle cases like > this. > > Regards > jonathan > |
From: Jonathan W. <jw...@ju...> - 2012-04-13 00:43:06
|
Hi Yves > >Could you try another simple test: > > - start ffado-mixer > > - start jackd at a rate different to that displayed by ffado-mixer > > - try to change the sample rate in ffado-mixer to something different to > > that used by jackd. > > > >I suspect that after dismissing the error dialog, ffado-mixer will just > >display the sample rate you selected, which obviously is not the sample rate > >in use by jackd. Irrespective of whether this suspicion is correct, it will > >tell us quite a bit about what's going on here. > > This is the result of the test: > 1) I start ffado-mixer and select 96000 Hz. > 2) I open jackd, select 41000 Hz and start jackd > 3) I try to select 48000 Hz with ffado-mixer while jackd is runing > 4) while the error popup is displayed, the sampling rate shown by > ffado-mixer is 48000 Hz > 5) when I close the popup, ffado-mixer shows a sampling rate of 41000 Hz. Thanks for doing this; the results are most interesting. It's a combination of what I expected plus some other things. > >Can you also tell me if the "streaming status" in ffado-mixer changes when > >jackd starts? > The two buttons under "streaming status" are dimmed when I start > ffado-mixer, and they remain dimmed when I start jackd. >From memory I think they are always "dimmed". There is a checkbox next to each which indicates the actual status. When functioning correctly there will be a tick in both the outgoing and incoming boxes when jackd is active, and when jackd is not running both boxes will be blank. When jackd is running (whether started before or after ffado-mixer) do you ever see the ticks, or do the boxes remain empty regardless of whether jackd is running? Regards jonathan |
From: Yves G. <yve...@te...> - 2012-04-13 07:05:07
|
----- Mail original ----- > De: "Jonathan Woithe" <jw...@ju...> > À: "Yves Grenier" <yve...@nu...> > Cc: ffa...@li... > Envoyé: Vendredi 13 Avril 2012 02:42:51 > Objet: Re: [FFADO-devel] Tests with Audiofire Saffire Pro24 > > Hi Yves > > > >Could you try another simple test: > > > - start ffado-mixer > > > - start jackd at a rate different to that displayed by > > > ffado-mixer > > > - try to change the sample rate in ffado-mixer to something > > > different to > > > that used by jackd. > > > > > >I suspect that after dismissing the error dialog, ffado-mixer will > > >just > > >display the sample rate you selected, which obviously is not the > > >sample rate > > >in use by jackd. Irrespective of whether this suspicion is > > >correct, it will > > >tell us quite a bit about what's going on here. > > > > This is the result of the test: > > 1) I start ffado-mixer and select 96000 Hz. > > 2) I open jackd, select 41000 Hz and start jackd > > 3) I try to select 48000 Hz with ffado-mixer while jackd is runing > > 4) while the error popup is displayed, the sampling rate shown by > > ffado-mixer is 48000 Hz > > 5) when I close the popup, ffado-mixer shows a sampling rate of > > 41000 Hz. > > Thanks for doing this; the results are most interesting. It's a > combination of what I expected plus some other things. > > > >Can you also tell me if the "streaming status" in ffado-mixer > > >changes when > > >jackd starts? > > The two buttons under "streaming status" are dimmed when I start > > ffado-mixer, and they remain dimmed when I start jackd. > > >From memory I think they are always "dimmed". There is a checkbox > >next to > each which indicates the actual status. When functioning correctly > there > will be a tick in both the outgoing and incoming boxes when jackd is > active, > and when jackd is not running both boxes will be blank. When jackd > is > running (whether started before or after ffado-mixer) do you ever see > the > ticks, or do the boxes remain empty regardless of whether jackd is > running? Hi Jonathan The two boxes remain empty whether jackd is running or not. Regards Yves |
From: Jonathan W. <jw...@ju...> - 2012-04-13 07:03:22
|
Hi Yves > > > >Can you also tell me if the "streaming status" in ffado-mixer > > > >changes when > > > >jackd starts? > > > The two buttons under "streaming status" are dimmed when I start > > > ffado-mixer, and they remain dimmed when I start jackd. > > > > From memory I think they are always "dimmed". There is a checkbox next > > to each which indicates the actual status. When functioning correctly > > there will be a tick in both the outgoing and incoming boxes when jackd > > is active, and when jackd is not running both boxes will be blank. When > > jackd is running (whether started before or after ffado-mixer) do you > > ever see the ticks, or do the boxes remain empty regardless of whether > > jackd is running? > > The two boxes remain empty whether jackd is running or not. Great - thanks for confirming this. That's pretty much what I expected. It means that for these devices the streaming status isn't being communicated back to ffado-mixer, so ffado-mixer has no idea that jackd has started. Once this is fixed the streaming status boxes will show ticks when jackd is active and the sample rate control will be locked against user interaction. This will also provide a hook which will allow ffado-mixer's sample rate display to be updated if jackd happens to change the sample rate. The next question is how to obtain the streaming status from the device. As mentioned earlier, the "generic AVC" function isn't appropriate for these devices. That probably requires some input from someone who has access to the protocol specification. In the meantime I'll dig through the source and see if there are any clues. Regards jonathan |
From: Jonathan W. <jw...@ju...> - 2012-04-16 12:56:09
|
Hi Yves > > > This is the result of the test: > > > 1) I start ffado-mixer and select 96000 Hz. > > > 2) I open jackd, select 41000 Hz and start jackd > > > 3) I try to select 48000 Hz with ffado-mixer while jackd is runing > > > 4) while the error popup is displayed, the sampling rate shown by > > > ffado-mixer is 48000 Hz > > > 5) when I close the popup, ffado-mixer shows a sampling rate of > > > 41000 Hz. > > > > Thanks for doing this; the results are most interesting. It's a > > combination of what I expected plus some other things. Ok, svn revision 2119 implements one piece of this puzzle. If ffado-mixer is running and jackd is started at a different sample rate, the rate displayed by ffado-mixer will now be automatically adjusted accordingly. > > > >Can you also tell me if the "streaming status" in ffado-mixer changes > > > >when jackd starts? > : > The two boxes remain empty whether jackd is running or not. This illustrates what I believe to be the last remaining aspect of this email discussion. For devices like yours (the Saffire Pro), ffado-mixer is never told when streaming starts. This is almost certainly because the Dice device object doesn't override the FFFADODevice::getStreamingState() method, and the default method doesn't apply to the Saffire devices. To totally solve this problem we need a way that the dice device object can determine the streaming status of the interface. To this end, svn revision 2120 is a first pass at implementing this missing functionality. Theoretically, if it works it means that ffado-mixer will now detect when streaming is started: the streaming status boxes will gain ticks, the correct sample rate (as used by jackd) will be reflected in the sample rate control and the sample rate control will be disabled to prevent user interaction. When jackd is stopped these changes (except the sample rate change) will be reversed - the device sample rate will remain at that set by jackd. Note that the changes in r2120 are compile-tested only: I don't own any DICE-based devices and so I cannot runtime test the code. Errors are therefore not entirely unexpected. Please test r2120 (or later) and report your findings. Regards jonathan |
From: Yves G. <yve...@nu...> - 2012-04-16 18:05:09
|
Le 16/04/2012 14:55, Jonathan Woithe a écrit : > Hi Yves > >>>> This is the result of the test: >>>> 1) I start ffado-mixer and select 96000 Hz. >>>> 2) I open jackd, select 41000 Hz and start jackd >>>> 3) I try to select 48000 Hz with ffado-mixer while jackd is runing >>>> 4) while the error popup is displayed, the sampling rate shown by >>>> ffado-mixer is 48000 Hz >>>> 5) when I close the popup, ffado-mixer shows a sampling rate of >>>> 41000 Hz. >>> Thanks for doing this; the results are most interesting. It's a >>> combination of what I expected plus some other things. > Ok, svn revision 2119 implements one piece of this puzzle. If ffado-mixer > is running and jackd is started at a different sample rate, the rate > displayed by ffado-mixer will now be automatically adjusted accordingly. > >>>>> Can you also tell me if the "streaming status" in ffado-mixer changes >>>>> when jackd starts? >> : >> The two boxes remain empty whether jackd is running or not. > This illustrates what I believe to be the last remaining aspect of this > email discussion. For devices like yours (the Saffire Pro), ffado-mixer is > never told when streaming starts. This is almost certainly because the Dice > device object doesn't override the FFFADODevice::getStreamingState() method, > and the default method doesn't apply to the Saffire devices. To totally > solve this problem we need a way that the dice device object can determine > the streaming status of the interface. > > To this end, svn revision 2120 is a first pass at implementing this missing > functionality. Theoretically, if it works it means that ffado-mixer will > now detect when streaming is started: the streaming status boxes will gain > ticks, the correct sample rate (as used by jackd) will be reflected in the > sample rate control and the sample rate control will be disabled to prevent > user interaction. When jackd is stopped these changes (except the sample > rate change) will be reversed - the device sample rate will remain at that > set by jackd. > > Note that the changes in r2120 are compile-tested only: I don't own any > DICE-based devices and so I cannot runtime test the code. Errors are > therefore not entirely unexpected. > > Please test r2120 (or later) and report your findings. > > Regards > jonathan > Hi Jonathan I compiled r2122 and tested. Everything works as expected. * The rate displayed by ffado-mixer is effectively adjusted when changed by jackd. * "Stream Status" shows ticks when jackd is started (both Incoming and Outgoing). * "Clock source" and "Sampling rate" are greyed when jackd starts and are no longer activated by clicking the mouse. Nice work! Regards Yves |
From: Jonathan W. <jw...@ju...> - 2012-04-17 02:42:14
|
Hi Yves On Mon, Apr 16, 2012 at 08:04:52PM +0200, Yves Grenier wrote: > >Please test r2120 (or later) and report your findings. > : > I compiled r2122 and tested. Everything works as expected. > > * The rate displayed by ffado-mixer is effectively adjusted when > changed by jackd. > * "Stream Status" shows ticks when jackd is started (both Incoming > and Outgoing). > * "Clock source" and "Sampling rate" are greyed when jackd starts > and are no longer activated by clicking the mouse. Great! Thanks for testing this and confirming that the issues are now resolved. > Nice work! Thanks. :-) Regards jonathan |
From: Jonathan W. <jw...@ju...> - 2012-03-31 09:52:35
|
Hi Yves > I just compiled revision 2102 and I got these warnings: > src/dice/dice_eap.cpp: In member function ?virtual void > Dice::EAP::Router::show()?: > src/dice/dice_eap.cpp:1613: warning: format ?%ld? expects type ?long > int?, but argument 7 has type ?size_t? > src/dice/dice_eap.cpp:1618: warning: format ?%ld? expects type ?long > int?, but argument 7 has type ?size_t? > src/dice/dice_eap.cpp: In member function ?void > Dice::EAP::RouterConfig::show()?: > src/dice/dice_eap.cpp:1801: warning: format ?%ld? expects type ?long > int?, but argument 7 has type ?size_t? > > These are just warnings, without impact, but a simple cast could fix it. Thanks for the report. A fix has been committed in r2103. As per the commit log, I've gone for "unsigned long long" because size_t could be 64-bit (as it is on 64-bit systems). Even though the values concerned won't exceed the maximum of a 32-bit unsigned integer in the context of these particular warnings, we should do things "correctly" anyway. The best solution to the problem is to use %zu, which is one of the "%z" specifiers introduced in C99 to cater for these built-in types (the "u" is for "unsigned", since size_t is unsigned). However, at this stage we shouldn't start assuming that the compiler used by every FFADO tester is C99-compliant and/or has support for this specifier (note however that I have done no research into gcc's support of %zu - if it turns out that it is widely supported perhaps we could consider using it). Regards jonathan |