From: Yves G. <yve...@te...> - 2013-05-24 06:56:13
Attachments:
EchoAudiofirePre8Discover.txt
|
Hi I was using three Echo Audiofire Pre8 boxes with ubuntu 10.04. My machine was recently ugraded to Ubuntu 12.04 (this was not my decision!). The firmware of the box is in the latest version (5.3). Jack works, but the channels are no longer recognized. They get names like these ones: firewire_pcm:001486059d5c9c6f_Unknown_in (for channel 1) firewire_pcm:001486059d5c9c6f_Unknown0_in (for channel 2) firewire_pcm:001486059d5c9c6f_Unknown1_in (for channel 3) ... I am joining the result of "ffado-test Discover" Best regards Yves Grenier |
From: Jonathan W. <jw...@ju...> - 2013-05-24 11:46:59
|
Hi Yves > I was using three Echo Audiofire Pre8 boxes with ubuntu 10.04. My machine > was recently ugraded to Ubuntu 12.04 (this was not my decision!). The > firmware of the box is in the latest version (5.3). > > Jack works, but the channels are no longer recognized. They get names like these ones: > firewire_pcm:001486059d5c9c6f_Unknown_in (for channel 1) > firewire_pcm:001486059d5c9c6f_Unknown0_in (for channel 2) > firewire_pcm:001486059d5c9c6f_Unknown1_in (for channel 3) > ... By "Jack works" do you mean that you can send audio to the device and receive audio from it? That is, are we talking about the naming of the channels only? What channel names were you seeing with the previous setup? Was your audiofire loaded with firmware 5.3 when you were using it with your previous setup? I'm not sure how the audiofire derives the names of the channels. I'll have to check this out to determine what might have changed. > I am joining the result of "ffado-test Discover" This is interesting. > 1369376915312147: Debug (avc_audiosubunit.cpp)[ 56] discover: Discovering AVC::AudioSubunit... > 1369376915312173: Debug (avc_subunit.cpp)[ 108] discoverPlugs: Discovering plugs... > 1369376915312502: Debug (avc_subunit.cpp)[ 228] initPlugFromDescriptor: plug loading from descriptor not implemented > 1369376915312528: Debug (avc_plug.cpp)[ 182] discover: discover: Could not init plug from descriptor (0,1,0,0,0) > 1369376915313510: Debug (avc_subunit.cpp)[ 228] initPlugFromDescriptor: plug loading from descriptor not implemented > 1369376915313538: Debug (avc_plug.cpp)[ 182] discover: discover: Could not init plug from descriptor (0,1,0,1,0) > 1369376915314370: Debug (avc_musicsubunit.cpp)[ 65] discover: Discovering MusicSubunit... > 1369376915314397: Debug (avc_subunit.cpp)[ 108] discoverPlugs: Discovering plugs... > 1369376915323637: Debug (avc_unit.cpp)[ 366] discoverPlugs: Discovering plugs... > 1369376915324047: Debug (avc_unit.cpp)[ 383] discoverPlugs: number of iso input plugs = 1 > 1369376915324086: Debug (avc_unit.cpp)[ 385] discoverPlugs: number of iso output plugs = 1 > 1369376915324131: Debug (avc_unit.cpp)[ 387] discoverPlugs: number of external input plugs = 3 > 1369376915324162: Debug (avc_unit.cpp)[ 389] discoverPlugs: number of external output plugs = 3 > 1369376915324189: Debug (avc_unit.cpp)[ 426] discoverPlugsPCR: Discovering PCR plugs, direction 0... > 1369376915324905: Debug (avc_plug.cpp)[ 487] discoverStreamFormat: Number of channels mismatch: 'PCR Unknown Input' plug discovering reported 17 channels for cluster 'Unknown', while stream format reported 8 > 1369376915324943: Debug (avc_plug.cpp)[ 457] discoverStreamFormat: No matching cluster info found for index 2 > 1369376915324977: Debug (avc_plug.cpp)[ 457] discoverStreamFormat: No matching cluster info found for index 3 > 1369376915325327: Debug (avc_unit.cpp)[ 448] discoverPlugsPCR: plug 'PCR Unknown Input' found It seems the parsing of information from the interface goes bad. I know that FFADO has difficulties with other AudioFire interfaces with the latest firmware and I wonder whether this is a variation on those symptoms. Regards jonathan |
From: Yves G. <yve...@te...> - 2013-05-24 12:42:47
|
Hi ----- Mail original ----- > De: "Jonathan Woithe" <jw...@ju...> > À: "Yves Grenier" <yve...@te...> > Cc: ffa...@li..., jw...@ju... > Envoyé: Vendredi 24 Mai 2013 13:46:15 > Objet: Re: [FFADO-devel] Channels not recognized (Echo Audiofire Pre8 + Ubuntu 12.04) > > Hi Yves > > > I was using three Echo Audiofire Pre8 boxes with ubuntu 10.04. My > > machine > > was recently ugraded to Ubuntu 12.04 (this was not my decision!). > > The > > firmware of the box is in the latest version (5.3). > > > > Jack works, but the channels are no longer recognized. They get > > names like these ones: > > firewire_pcm:001486059d5c9c6f_Unknown_in (for channel 1) > > firewire_pcm:001486059d5c9c6f_Unknown0_in (for channel 2) > > firewire_pcm:001486059d5c9c6f_Unknown1_in (for channel 3) > > ... > > By "Jack works" do you mean that you can send audio to the device and > receive audio from it? That is, are we talking about the naming of > the > channels only? Yes I can send and receive audio. The only problem is the naming. > > What channel names were you seeing with the previous setup? I need to access to this machine to check it, and I will not be able to do it this afternoon. I'll tell you later. > > Was your audiofire loaded with firmware 5.3 when you were using it > with your > previous setup? Yes the firmware was the same. The main change was to replace the old firewire stack (in 10.04) by the new one. I was using svn version 4222, and now I am using the latest version. > > I'm not sure how the audiofire derives the names of the channels. > I'll have > to check this out to determine what might have changed. > > > I am joining the result of "ffado-test Discover" > > This is interesting. > > > 1369376915312147: Debug (avc_audiosubunit.cpp)[ 56] discover: > > Discovering AVC::AudioSubunit... > > 1369376915312173: Debug (avc_subunit.cpp)[ 108] discoverPlugs: > > Discovering plugs... > > 1369376915312502: Debug (avc_subunit.cpp)[ 228] > > initPlugFromDescriptor: plug loading from descriptor not > > implemented > > 1369376915312528: Debug (avc_plug.cpp)[ 182] discover: discover: > > Could not init plug from descriptor (0,1,0,0,0) > > 1369376915313510: Debug (avc_subunit.cpp)[ 228] > > initPlugFromDescriptor: plug loading from descriptor not > > implemented > > 1369376915313538: Debug (avc_plug.cpp)[ 182] discover: discover: > > Could not init plug from descriptor (0,1,0,1,0) > > 1369376915314370: Debug (avc_musicsubunit.cpp)[ 65] discover: > > Discovering MusicSubunit... > > 1369376915314397: Debug (avc_subunit.cpp)[ 108] discoverPlugs: > > Discovering plugs... > > 1369376915323637: Debug (avc_unit.cpp)[ 366] discoverPlugs: > > Discovering plugs... > > 1369376915324047: Debug (avc_unit.cpp)[ 383] discoverPlugs: number > > of iso input plugs = 1 > > 1369376915324086: Debug (avc_unit.cpp)[ 385] discoverPlugs: number > > of iso output plugs = 1 > > 1369376915324131: Debug (avc_unit.cpp)[ 387] discoverPlugs: number > > of external input plugs = 3 > > 1369376915324162: Debug (avc_unit.cpp)[ 389] discoverPlugs: number > > of external output plugs = 3 > > 1369376915324189: Debug (avc_unit.cpp)[ 426] discoverPlugsPCR: > > Discovering PCR plugs, direction 0... > > 1369376915324905: Debug (avc_plug.cpp)[ 487] discoverStreamFormat: > > Number of channels mismatch: 'PCR Unknown Input' plug discovering > > reported 17 channels for cluster 'Unknown', while stream format > > reported 8 > > 1369376915324943: Debug (avc_plug.cpp)[ 457] discoverStreamFormat: > > No matching cluster info found for index 2 > > 1369376915324977: Debug (avc_plug.cpp)[ 457] discoverStreamFormat: > > No matching cluster info found for index 3 > > 1369376915325327: Debug (avc_unit.cpp)[ 448] discoverPlugsPCR: plug > > 'PCR Unknown Input' found > > It seems the parsing of information from the interface goes bad. I > know > that FFADO has difficulties with other AudioFire interfaces with the > latest > firmware and I wonder whether this is a variation on those symptoms. > > Regards > jonathan > Regards Yves |
From: Yves G. <yve...@te...> - 2013-05-24 14:26:05
|
Hi Concerning the previous names of the channels, they were system:capture_1 system:capture_2 system:capture_3 ... system:capture_8 system:output_1 ... This was with the old firewire stack. Regards Yves ----- Mail original ----- > De: "Yves Grenier" <yve...@te...> > À: "Jonathan Woithe" <jw...@ju...> > Cc: ffa...@li... > Envoyé: Vendredi 24 Mai 2013 14:42:36 > Objet: Re: [FFADO-devel] Channels not recognized (Echo Audiofire Pre8 + Ubuntu 12.04) > > Hi > > ----- Mail original ----- > > De: "Jonathan Woithe" <jw...@ju...> > > À: "Yves Grenier" <yve...@te...> > > Cc: ffa...@li..., jw...@ju... > > Envoyé: Vendredi 24 Mai 2013 13:46:15 > > Objet: Re: [FFADO-devel] Channels not recognized (Echo Audiofire > > Pre8 + Ubuntu 12.04) > > > > Hi Yves > > > > > I was using three Echo Audiofire Pre8 boxes with ubuntu 10.04. My > > > machine > > > was recently ugraded to Ubuntu 12.04 (this was not my decision!). > > > The > > > firmware of the box is in the latest version (5.3). > > > > > > Jack works, but the channels are no longer recognized. They get > > > names like these ones: > > > firewire_pcm:001486059d5c9c6f_Unknown_in (for channel 1) > > > firewire_pcm:001486059d5c9c6f_Unknown0_in (for channel 2) > > > firewire_pcm:001486059d5c9c6f_Unknown1_in (for channel 3) > > > ... > > > > By "Jack works" do you mean that you can send audio to the device > > and > > receive audio from it? That is, are we talking about the naming of > > the > > channels only? > > Yes I can send and receive audio. The only problem is the naming. > > > > > What channel names were you seeing with the previous setup? > > I need to access to this machine to check it, and I will not be able > to do it this afternoon. I'll tell you later. > > > > > Was your audiofire loaded with firmware 5.3 when you were using it > > with your > > previous setup? > > Yes the firmware was the same. The main change was to replace the old > firewire stack (in 10.04) by the new one. I was using svn version > 4222, and now I am using the latest version. > > > > > I'm not sure how the audiofire derives the names of the channels. > > I'll have > > to check this out to determine what might have changed. > > > > > I am joining the result of "ffado-test Discover" > > > > This is interesting. > > > > > 1369376915312147: Debug (avc_audiosubunit.cpp)[ 56] discover: > > > Discovering AVC::AudioSubunit... > > > 1369376915312173: Debug (avc_subunit.cpp)[ 108] discoverPlugs: > > > Discovering plugs... > > > 1369376915312502: Debug (avc_subunit.cpp)[ 228] > > > initPlugFromDescriptor: plug loading from descriptor not > > > implemented > > > 1369376915312528: Debug (avc_plug.cpp)[ 182] discover: discover: > > > Could not init plug from descriptor (0,1,0,0,0) > > > 1369376915313510: Debug (avc_subunit.cpp)[ 228] > > > initPlugFromDescriptor: plug loading from descriptor not > > > implemented > > > 1369376915313538: Debug (avc_plug.cpp)[ 182] discover: discover: > > > Could not init plug from descriptor (0,1,0,1,0) > > > 1369376915314370: Debug (avc_musicsubunit.cpp)[ 65] discover: > > > Discovering MusicSubunit... > > > 1369376915314397: Debug (avc_subunit.cpp)[ 108] discoverPlugs: > > > Discovering plugs... > > > 1369376915323637: Debug (avc_unit.cpp)[ 366] discoverPlugs: > > > Discovering plugs... > > > 1369376915324047: Debug (avc_unit.cpp)[ 383] discoverPlugs: > > > number > > > of iso input plugs = 1 > > > 1369376915324086: Debug (avc_unit.cpp)[ 385] discoverPlugs: > > > number > > > of iso output plugs = 1 > > > 1369376915324131: Debug (avc_unit.cpp)[ 387] discoverPlugs: > > > number > > > of external input plugs = 3 > > > 1369376915324162: Debug (avc_unit.cpp)[ 389] discoverPlugs: > > > number > > > of external output plugs = 3 > > > 1369376915324189: Debug (avc_unit.cpp)[ 426] discoverPlugsPCR: > > > Discovering PCR plugs, direction 0... > > > 1369376915324905: Debug (avc_plug.cpp)[ 487] > > > discoverStreamFormat: > > > Number of channels mismatch: 'PCR Unknown Input' plug discovering > > > reported 17 channels for cluster 'Unknown', while stream format > > > reported 8 > > > 1369376915324943: Debug (avc_plug.cpp)[ 457] > > > discoverStreamFormat: > > > No matching cluster info found for index 2 > > > 1369376915324977: Debug (avc_plug.cpp)[ 457] > > > discoverStreamFormat: > > > No matching cluster info found for index 3 > > > 1369376915325327: Debug (avc_unit.cpp)[ 448] discoverPlugsPCR: > > > plug > > > 'PCR Unknown Input' found > > > > It seems the parsing of information from the interface goes bad. I > > know > > that FFADO has difficulties with other AudioFire interfaces with > > the > > latest > > firmware and I wonder whether this is a variation on those > > symptoms. > > > > Regards > > jonathan > > > > Regards > > Yves > > ------------------------------------------------------------------------------ > Try New Relic Now & We'll Send You this Cool Shirt > New Relic is the only SaaS-based application performance monitoring > service > that delivers powerful full stack analytics. Optimize and monitor > your > browser, app, & servers with just a few lines of code. Try New Relic > and get this awesome Nerd Life shirt! > http://p.sf.net/sfu/newrelic_d2d_may > _______________________________________________ > FFADO-devel mailing list > FFA...@li... > https://lists.sourceforge.net/lists/listinfo/ffado-devel > |
From: Jonathan W. <jw...@ju...> - 2013-05-25 00:19:10
|
Hi Yves On Fri, May 24, 2013 at 04:25:56PM +0200, Yves Grenier wrote: > Concerning the previous names of the channels, they were > system:capture_1 > system:capture_2 > system:capture_3 > ... > system:capture_8 > system:output_1 > ... Thanks for this. Is there any chance you could provide the "ffado-test Discover" output from this other machine as well? I am interested to see how the parsing proceeds there. > This was with the old firewire stack. It's hard to see how this could affect the channel names, but it's something to keep in mind. Maybe there's something about the new stack that's upsetting the parsing in some strange way. Regards jonathan |
From: Yves G. <yve...@te...> - 2013-05-27 05:48:54
|
Hi ----- Mail original ----- > De: "Jonathan Woithe" <jw...@ju...> > À: "Yves Grenier" <yve...@te...> > Cc: ffa...@li..., jw...@ju... > Envoyé: Samedi 25 Mai 2013 02:18:48 > Objet: Re: [FFADO-devel] Channels not recognized (Echo Audiofire Pre8 + Ubuntu 12.04) > > Hi Yves > > On Fri, May 24, 2013 at 04:25:56PM +0200, Yves Grenier wrote: > > Concerning the previous names of the channels, they were > > system:capture_1 > > system:capture_2 > > system:capture_3 > > ... > > system:capture_8 > > system:output_1 > > ... > > Thanks for this. Is there any chance you could provide the > "ffado-test > Discover" output from this other machine as well? I am interested to > see > how the parsing proceeds there. No unfortunately, this is not possible. This machine was upgraded to ubuntu 12.04. I could get the previous names from a log file that I had kept on this machine. Sorry Yves > > > This was with the old firewire stack. > > It's hard to see how this could affect the channel names, but it's > something > to keep in mind. Maybe there's something about the new stack that's > upsetting the parsing in some strange way. > > Regards > jonathan > |
From: Stefan R. <st...@s5...> - 2013-05-25 08:47:04
|
On May 25 Jonathan Woithe wrote: > Hi Yves > > On Fri, May 24, 2013 at 04:25:56PM +0200, Yves Grenier wrote: [...] > >>> Jack works, but the channels are no longer recognized. They get names like these ones: > >>> firewire_pcm:001486059d5c9c6f_Unknown_in (for channel 1) > >>> firewire_pcm:001486059d5c9c6f_Unknown0_in (for channel 2) > >>> firewire_pcm:001486059d5c9c6f_Unknown1_in (for channel 3) [...] > > Concerning the previous names of the channels, they were > > system:capture_1 > > system:capture_2 > > system:capture_3 > > ... > > system:capture_8 > > system:output_1 > > ... > > Thanks for this. Is there any chance you could provide the "ffado-test > Discover" output from this other machine as well? I am interested to see > how the parsing proceeds there. > > > This was with the old firewire stack. > > It's hard to see how this could affect the channel names, but it's > something to keep in mind. Maybe there's something about the new stack > that's upsetting the parsing in some strange way. Jonathan, wasn't there a policy change in FFADO regarding channel naming? Yves, does "jack_lsp -A" not show what it should show? (And in qjackctl, there are a toggle button and a popup menu in "Setup..."/ "Display" which affect which of the port aliases are chosen for display by qjackctl.) -- Stefan Richter -=====-===-= -=-= ==--= http://arcgraph.de/sr/ |
From: Jonathan W. <jw...@ju...> - 2013-05-25 10:17:51
|
On Sat, May 25, 2013 at 10:14:38AM +0200, Stefan Richter wrote: > On May 25 Jonathan Woithe wrote: > > Hi Yves > > > > On Fri, May 24, 2013 at 04:25:56PM +0200, Yves Grenier wrote: > [...] > > >>> Jack works, but the channels are no longer recognized. They get names like these ones: > > >>> firewire_pcm:001486059d5c9c6f_Unknown_in (for channel 1) > > >>> firewire_pcm:001486059d5c9c6f_Unknown0_in (for channel 2) > > >>> firewire_pcm:001486059d5c9c6f_Unknown1_in (for channel 3) > [...] > > > Concerning the previous names of the channels, they were > > > system:capture_1 > > > system:capture_2 > > > system:capture_3 > > > ... > > > system:capture_8 > > > system:output_1 > > > ... > > : > > > This was with the old firewire stack. > > > > It's hard to see how this could affect the channel names, but it's > > something to keep in mind. Maybe there's something about the new stack > > that's upsetting the parsing in some strange way. > > Jonathan, wasn't there a policy change in FFADO regarding channel naming? There was. When FFADO first appeared, the jack port names would be descriptive where it made sense to be so for a given device. So you might have system:mic_1, system:phones_L and so on. Later on it was decided that having generic names would make it easier to move things between systems with different interfaces, so FFADO changed to using names like system:capture_1 and so on. This brought consistency between ports provided by the FFADO and ALSA jack backends. In most cases this brought about a swap between the port names reported by "jack_lsp" and "jack_lsp -A". In other words, the name and first alias of the ports were swapped around. In Yves's case, his older system provided names like system:capture_1, which matches the current behaviour. We can conclude here that the jackd/ffado on the older system was more recent than the policy change you eluded to. I guess the mystery here is why the newer system is using what for all intents and purposes appears to be the older port naming convention. > Yves, does "jack_lsp -A" not show what it should show? (And in qjackctl, > there are a toggle button and a popup menu in "Setup..."/ "Display" which > affect which of the port aliases are chosen for display by qjackctl.) Good point. In the above response I'm assuming that we're talking about the port names provided by "jack_lsp" - that is, the port names rather than the aliases. Perhaps the software concerned is set up to show the aliases instead. That could match the symptoms reported: on the older system the alias used the system:* pattern, whereas on newer jackd/ffado it would give the "descriptive" port names. Regards jonathan |
From: Yves G. <yve...@te...> - 2013-05-27 06:43:45
Attachments:
jack_lsp.txt
|
Hi Stephan ----- Mail original ----- > De: "Stefan Richter" <st...@s5...> > À: "Jonathan Woithe" <jw...@ju...>, "Yves Grenier" <yve...@te...> > Cc: ffa...@li... > Envoyé: Samedi 25 Mai 2013 10:14:38 > Objet: Re: [FFADO-devel] Channels not recognized (Echo Audiofire Pre8 + Ubuntu 12.04) > > On May 25 Jonathan Woithe wrote: > > Hi Yves > > > > On Fri, May 24, 2013 at 04:25:56PM +0200, Yves Grenier wrote: > [...] > > >>> Jack works, but the channels are no longer recognized. They get > > >>> names like these ones: > > >>> firewire_pcm:001486059d5c9c6f_Unknown_in (for channel 1) > > >>> firewire_pcm:001486059d5c9c6f_Unknown0_in (for channel 2) > > >>> firewire_pcm:001486059d5c9c6f_Unknown1_in (for channel 3) > [...] > > > Concerning the previous names of the channels, they were > > > system:capture_1 > > > system:capture_2 > > > system:capture_3 > > > ... > > > system:capture_8 > > > system:output_1 > > > ... > > > > Thanks for this. Is there any chance you could provide the > > "ffado-test > > Discover" output from this other machine as well? I am interested > > to see > > how the parsing proceeds there. > > > > > This was with the old firewire stack. > > > > It's hard to see how this could affect the channel names, but it's > > something to keep in mind. Maybe there's something about the new > > stack > > that's upsetting the parsing in some strange way. > > Jonathan, wasn't there a policy change in FFADO regarding channel > naming? > > Yves, does "jack_lsp -A" not show what it should show? I join the result of this command (file jack_lsp.txt) > (And in > qjackctl, > there are a toggle button and a popup menu in "Setup..."/ "Display" > which > affect which of the port aliases are chosen for display by qjackctl.) I did tests with the toggle button on/off and with the three selections in the menu ("Default","First","Second") The toggle button does not seem to have any effect. I get channel names starting with "system" only if I select "First", otherwise I get these longer names but qjackctl shows "firewire_pcm:001486059d5c9c6f_Unknown_in" as the last channel in the list, whereas it should be the first. The strange thing is that if stop/start the connection within qjackctl, then I only get 12 channels instead of 16 (I observe this behaviour for all tests: button on/off, all three menu selections). The only way to recover 16 channels is to power off and on the Echo box! Regards Yves > -- > Stefan Richter > -=====-===-= -=-= ==--= > http://arcgraph.de/sr/ > |
From: Jonathan W. <jw...@ju...> - 2013-05-27 07:14:27
|
Hi Yves > > Jonathan, wasn't there a policy change in FFADO regarding channel > > naming? > > > > Yves, does "jack_lsp -A" not show what it should show? > > I join the result of this command (file jack_lsp.txt) > : > firewire_pcm:001486059d5c9c6f_Unknown_in > system:capture_1 > firewire_pcm:001486059d5c9c6f_Unknown0_in > system:capture_2 > : Hmm, that's interesting. I think this indicates that the "long" names are the real names and the "system" names are the aliases. That is the reverse of what I would expect. The decision as to what to use as jack port names isn't made within ffado itself but rather in the "firewire" jack backend. Although it seems very unlikely, I wonder whether jack is picking up an old "firewire" backend from somewhere. I think the backends live in /usr/lib/jack or /usr/local/lib/jack depending on how jackd was compiled and installed. It might be worth checking in these (and maybe other) locations for rogue jack_firewire.so files. I recall you saying that ffado 2.1.0 was installed on this box (please correct me if I'm wrong here). Could you confirm what version of jack is installed: "jackd --version" in a terminal should do. Also, could you send the output produced when you start jack. The can be either from the qjackctl console or from a terminal when you run jack manually: jackd -R -P70 -d firewire -p 512 -n 3 -v 3 I'm most interested in the ffado version reported therein. The "-v 3" may not be needed to get this information. > > Thanks for this. Is there any chance you could provide the "ffado-test > > Discover" output from this other machine as well? I am interested to > > see how the parsing proceeds there. > > No unfortunately, this is not possible. This machine was upgraded to ubuntu > 12.04. I could get the previous names from a log file that I had kept on > this machine. Ok, fair enough. I see now how you were able to lay your hands on the old port name list. > I get channel names starting with "system" only if I select "First", > otherwise I get these longer names but qjackctl shows > "firewire_pcm:001486059d5c9c6f_Unknown_in" as the last channel in the > list, whereas it should be the first. As mentioned earlier I don't use qjackctl but it seems that this "default, first, second" control is selecting which names to display. "Default" would correspond to the port name, "First" to the first alias, and "Second" to the second alias if present (most drivers don't have more than one alias). Your description above is consistent with the "jack_lsp -A" output you gave: it indicates that the "long" strings are the actual port names while the shorter "system" ones are the aliases. For some reason the firewire backend is setting things up in the opposite manner to what would be expected. It really is as if an older firewire backend was in use. > The strange thing is that if stop/start the connection within qjackctl, > then I only get 12 channels instead of 16 (I observe this behaviour for > all tests: button on/off, all three menu selections). The only way to > recover 16 channels is to power off and on the Echo box! This sounds like a separate issue. However, if there are multiple versions of jackd, ffado and/or the jack firewire backend kicking around then it might be related. The switching of the port names is a problem I think; let's get to the bottom of that and then revisit this channel count issue if it still proves relevant. Regards jonathan |
From: Yves G. <yve...@te...> - 2013-05-27 07:44:25
|
Hi Jonathan ----- Mail original ----- > De: "Jonathan Woithe" <jw...@ju...> > À: "Yves Grenier" <yve...@te...> > Cc: "Stefan Richter" <st...@s5...>, ffa...@li..., jw...@ju... > Envoyé: Lundi 27 Mai 2013 09:14:06 > Objet: Re: [FFADO-devel] Channels not recognized (Echo Audiofire Pre8 + Ubuntu 12.04) > > Hi Yves > > > > Jonathan, wasn't there a policy change in FFADO regarding channel > > > naming? > > > > > > Yves, does "jack_lsp -A" not show what it should show? > > > > I join the result of this command (file jack_lsp.txt) > > : > > firewire_pcm:001486059d5c9c6f_Unknown_in > > system:capture_1 > > firewire_pcm:001486059d5c9c6f_Unknown0_in > > system:capture_2 > > : > > Hmm, that's interesting. I think this indicates that the "long" > names are > the real names and the "system" names are the aliases. That is the > reverse > of what I would expect. The decision as to what to use as jack port > names > isn't made within ffado itself but rather in the "firewire" jack > backend. > Although it seems very unlikely, I wonder whether jack is picking up > an old > "firewire" backend from somewhere. I think the backends live in > /usr/lib/jack or /usr/local/lib/jack depending on how jackd was > compiled and installed. It might be worth checking in these (and > maybe > other) locations for rogue jack_firewire.so files. I found only one jack_firewire.so: /usr/lib/i386-linux-gnu/jack/jack_firewire.so jack is installed /usr/lib/jack: $ ls -l /usr/lib/jack/ total 180 -rwxr-xr-x 1 root root 942 juil. 29 2012 a2j_in.la -rwxr-xr-x 1 root root 59257 juil. 29 2012 a2j_in.so -rwxr-xr-x 1 root root 960 juil. 29 2012 inprocess.la -rwxr-xr-x 1 root root 942 juil. 29 2012 intime.la -rwxr-xr-x 1 root root 1008 juil. 29 2012 jack_alsa.la -rwxr-xr-x 1 root root 1012 juil. 29 2012 jack_alsa_midi.la -rwxr-xr-x 1 root root 85069 juil. 29 2012 jack_alsa_midi.so -rwxr-xr-x 1 root root 992 juil. 29 2012 jack_dummy.la -rwxr-xr-x 1 root root 1060 juil. 29 2012 jack_firewire.la -rwxr-xr-x 1 root root 1000 juil. 29 2012 jack_net.la -rwxr-xr-x 1 root root 980 juil. 29 2012 jack_oss.la > > I recall you saying that ffado 2.1.0 was installed on this box The version installed by ubuntu is 2.0.99+svn2019-1ubuntu1 I compiled the svn version above this one, but I see that there are two version that coexist in /usr/lib: and /usr/lib/libffado2/. Is this a problem? $ ls -lt /usr/lib/libffado* lrwxrwxrwx 1 root root 20 mai 23 20:01 /usr/lib/libffado.so.2 -> libffado.so.2.1.9999 lrwxrwxrwx 1 root root 13 mai 23 20:01 /usr/lib/libffado.so -> libffado.so.2 -rwxrwxr-x 1 root root 10293263 mai 23 20:00 /usr/lib/libffado.so.2.1.9999 /usr/lib/libffado2: total 2004 -rw-r--r-- 1 root root 2050584 févr. 17 2012 libffado.so.2.999.0 lrwxrwxrwx 1 root root 19 févr. 17 2012 libffado.so.2 -> libffado.so.2.999.0 > (please > correct me if I'm wrong here). Could you confirm what version of > jack is > installed: "jackd --version" in a terminal should do. $ jackd --version jackdmp 1.9.8 > > Also, could you send the output produced when you start jack. The > can be > either from the qjackctl console or from a terminal when you run jack > manually: > > jackd -R -P70 -d firewire -p 512 -n 3 -v 3 > > I'm most interested in the ffado version reported therein. The "-v > 3" may > not be needed to get this information. $ jackd -R -P70 -d firewire -p 512 -n 3 -v 3 jackdmp 1.9.8 Copyright 2001-2005 Paul Davis and others. Copyright 2004-2011 Grame. jackdmp comes with ABSOLUTELY NO WARRANTY This is free software, and you are welcome to redistribute it under certain conditions; see the file COPYING for details no message buffer overruns no message buffer overruns no message buffer overruns JACK server starting in realtime mode with priority 70 1369640535084605: (ffado.cpp)[ 92] ffado_streaming_init: libffado 2.1.9999-2322M built May 23 2013 19:59:34 1369640535400364: Warning (StreamProcessor.cpp)[1708] updateState: ignoring identity state update from/to ePS_Created 1369640535400686: Warning (StreamProcessor.cpp)[1708] updateState: ignoring identity state update from/to ePS_Created 1369640536220622: Warning (StreamProcessor.cpp)[ 798] getPacket: Instantanous samplerate more than 1% off nominal. [Nom fs: 48000.000000, Instantanous fs: 16011.727339, diff: 31988.272661 ( 0.666422)] > > > > Thanks for this. Is there any chance you could provide the > > > "ffado-test > > > Discover" output from this other machine as well? I am > > > interested to > > > see how the parsing proceeds there. > > > > No unfortunately, this is not possible. This machine was upgraded > > to ubuntu > > 12.04. I could get the previous names from a log file that I had > > kept on > > this machine. > > Ok, fair enough. I see now how you were able to lay your hands on > the old > port name list. > > > I get channel names starting with "system" only if I select > > "First", > > otherwise I get these longer names but qjackctl shows > > "firewire_pcm:001486059d5c9c6f_Unknown_in" as the last channel in > > the > > list, whereas it should be the first. > > As mentioned earlier I don't use qjackctl but it seems that this > "default, > first, second" control is selecting which names to display. > "Default" would > correspond to the port name, "First" to the first alias, and "Second" > to the > second alias if present (most drivers don't have more than one > alias). Your > description above is consistent with the "jack_lsp -A" output you > gave: it > indicates that the "long" strings are the actual port names while the > shorter "system" ones are the aliases. For some reason the firewire > backend > is setting things up in the opposite manner to what would be > expected. It > really is as if an older firewire backend was in use. > > > The strange thing is that if stop/start the connection within > > qjackctl, > > then I only get 12 channels instead of 16 (I observe this behaviour > > for > > all tests: button on/off, all three menu selections). The only way > > to > > recover 16 channels is to power off and on the Echo box! > > This sounds like a separate issue. However, if there are multiple > versions > of jackd, ffado and/or the jack firewire backend kicking around then > it > might be related. The switching of the port names is a problem I > think; > let's get to the bottom of that and then revisit this channel count > issue if > it still proves relevant. I agree with you, let's first solve the problem with the port names, we will see the other one later if ii is still present. Best regards Yves > > Regards > jonathan > |
From: Jonathan W. <jw...@ju...> - 2013-05-27 10:04:54
|
Hi Yves For your information, here's what my development machine is currently giving me for the device that happens to be plugged in at the moment (RME Fireface800): > jack_lsp -A system:capture_1 firewire_pcm:C0_000a350076e71193_cap_analog-1 system:capture_2 firewire_pcm:C1_000a350076e71193_cap_analog-2 And so on. So the port name is "system:*" and the long names are the first alias. > > > I join the result of this command (file jack_lsp.txt) > > > : > > > firewire_pcm:001486059d5c9c6f_Unknown_in > > > system:capture_1 > > > firewire_pcm:001486059d5c9c6f_Unknown0_in > > > system:capture_2 > > > : > > > > Hmm, that's interesting. I think this indicates that the "long" names > > are the real names and the "system" names are the aliases. That is the > > reverse of what I would expect. The decision as to what to use as jack > > port names isn't made within ffado itself but rather in the "firewire" > > jack backend. Although it seems very unlikely, I wonder whether jack is > > picking up an old "firewire" backend from somewhere. I think the > > backends live in /usr/lib/jack or /usr/local/lib/jack depending on how > > jackd was compiled and installed. It might be worth checking in these > > (and maybe other) locations for rogue jack_firewire.so files. > > I found only one jack_firewire.so: > /usr/lib/i386-linux-gnu/jack/jack_firewire.so Ok. What's ls -la /usr/lib/i386-linux-gnu/jack/ give you? > jack is installed /usr/lib/jack: > $ ls -l /usr/lib/jack/ > total 180 > -rwxr-xr-x 1 root root 942 juil. 29 2012 a2j_in.la > -rwxr-xr-x 1 root root 59257 juil. 29 2012 a2j_in.so > -rwxr-xr-x 1 root root 960 juil. 29 2012 inprocess.la > -rwxr-xr-x 1 root root 942 juil. 29 2012 intime.la > -rwxr-xr-x 1 root root 1008 juil. 29 2012 jack_alsa.la > -rwxr-xr-x 1 root root 1012 juil. 29 2012 jack_alsa_midi.la > -rwxr-xr-x 1 root root 85069 juil. 29 2012 jack_alsa_midi.so > -rwxr-xr-x 1 root root 992 juil. 29 2012 jack_dummy.la > -rwxr-xr-x 1 root root 1060 juil. 29 2012 jack_firewire.la > -rwxr-xr-x 1 root root 1000 juil. 29 2012 jack_net.la > -rwxr-xr-x 1 root root 980 juil. 29 2012 jack_oss.la On my system all the driver .so files are present in /usr/local/lib/ (my install prefix is /usr/local/ compared to yours, which is /usr/). I'm very interested that the only jack_firewire.so is in what appears to be a non-standard destination for jack backend drivers. Furthermore, the firewire driver .la and .so are in different locations. That's different to what I'm normally used to seeing. > The version installed by ubuntu is 2.0.99+svn2019-1ubuntu1 > I compiled the svn version above this one, but I see that there are two > version that coexist in /usr/lib: and /usr/lib/libffado2/. Is this a > problem? > > $ ls -lt /usr/lib/libffado* > lrwxrwxrwx 1 root root 20 mai 23 20:01 /usr/lib/libffado.so.2 -> libffado.so.2.1.9999 > lrwxrwxrwx 1 root root 13 mai 23 20:01 /usr/lib/libffado.so -> libffado.so.2 > -rwxrwxr-x 1 root root 10293263 mai 23 20:00 /usr/lib/libffado.so.2.1.9999 > > /usr/lib/libffado2: > total 2004 > -rw-r--r-- 1 root root 2050584 févr. 17 2012 libffado.so.2.999.0 > lrwxrwxrwx 1 root root 19 févr. 17 2012 libffado.so.2 -> libffado.so.2.999.0 This can give rise to trouble, but the symptoms you've been seeing so far are not the typical ones for this situation (normally things complain about the incorrect library version, and similar). The reason it's not a problem is probaby because the old ubuntu version is tucked away in /usr/lib/libffado2/ and probably won't be found by executables. Even so, I think this ought to be fixed - which is easy to do, fortunately. All you should need to do is move /usr/lib/libffado2 to some other location (/tmp for example, or somewhere else less volatile): mv /usr/lib/libffado2 /tmp You'll obviously need to be root to do this. > $ jackd --version > jackdmp 1.9.8 That should be fine. > $ jackd -R -P70 -d firewire -p 512 -n 3 -v 3 > jackdmp 1.9.8 > : > 1369640535084605: (ffado.cpp)[ 92] ffado_streaming_init: libffado 2.1.9999-2322M built May 23 2013 19:59:34 Jack is picking up the correct libffado as far as I can tell. Over the next day or so I'll see if I can take a quick glance through the AudioFire code just to make sure there's nothing funny going on regarding port names. Regards jonathan |
From: Jonathan W. <jw...@ju...> - 2013-05-28 00:42:40
|
Hi Yves > > For your information, here's what my development machine is currently > > giving me for the device that happens to be plugged in at the moment > > (RME Fireface800): > > > > > jack_lsp -A > > system:capture_1 > > firewire_pcm:C0_000a350076e71193_cap_analog-1 > > system:capture_2 > > firewire_pcm:C1_000a350076e71193_cap_analog-2 > > > > And so on. So the port name is "system:*" and the long names are the > > first > > alias. > > > > > > > I join the result of this command (file jack_lsp.txt) > > > > > : > > > > > firewire_pcm:001486059d5c9c6f_Unknown_in > > > > > system:capture_1 > > > > > firewire_pcm:001486059d5c9c6f_Unknown0_in > > > > > system:capture_2 > > > > > : Here's a quick reply - I'm not at my development machine right now and so I can't confirm any of this until later today. I've been looking at the jack firewire backend code for both jack1 and jack2. In jack2, it seems that the port name is constructed with the following form: firewire_pcm:C<i>_<name> where <i> is a number which runs from 0 and <name> is the port name which comes from ffado. After setting the port name, an alias is created of the form system:<type>_<n> where <type> is either "capture" or "playback", and <n> is a number running from 1. A comment in the jack2 code indicates that these aliases are "jackd1 style port names". This arrangement exactly matches what you're seeing from "jack_lsp -A". I then look at the current jack1 firewire backend source, and somewhat surprisingly it matches jack2 with regard to the port name. However, it does not create the "system:*" aliases - at least not explicitly. This has me puzzled because clearly on my machine currently I'm seeing "system:*" names and "firewire_pcm:*" aliases. The most likely version of jack1 I'm running is 0.121.3 (the last release); I've checked that source code and it matches the current code in this respect. Putting all this together, it seems at face value that what you're seeing as jack port names is what the jack2 code intends. I am completely mystified as to why I'm not seeing the same thing omn jack1 given that jack1's code appears to be doing the same thing - this is something I'm going to have to investigate further when I'm back at my development PC. The only thing I can think of presently is that jack1 forces the "system:*" name and moves any user-specified name to the first alias. Another thing that this shows is that my recollection of the history about the naming convention of ffado jack ports is in error. I will have to go through the list archives to discover the truth. Assuming that the above analysis is correct and that there's nothing erroneous going on, the obvious question in your case is why all the channels are labelled as "unknown". These names are obtained from the device itself via the generic AVC layer, and if this fails "unknown" is used as a place holder. Given that these long names were hidden from you on the previous system (probaby due to a change in the port naming convention) it's possible that ffado has never been able to determine the AudioFile names on your device. It's only now, due to the explicit exposure of those port names by jack2, that it's noticeable. If this is the case it would certainly be good to identify the problem and fix it. > > Ok. What's > > > > ls -la /usr/lib/i386-linux-gnu/jack/ > > > > give you? > > $ ls -la /usr/lib/i386-linux-gnu/jack/ > total 444 > drwxr-xr-x 2 root root 4096 mai 14 10:25 . > drwxr-xr-x 64 root root 61440 mai 22 08:26 .. > -rw-r--r-- 1 root root 38724 mars 28 19:24 audioadapter.so > -rw-r--r-- 1 root root 5432 mars 28 19:24 inprocess.so > -rw-r--r-- 1 root root 97052 mars 28 19:24 jack_alsa.so > -rw-r--r-- 1 root root 13816 mars 28 19:24 jack_dummy.so > -rw-r--r-- 1 root root 34512 mars 28 19:24 jack_firewire.so > -rw-r--r-- 1 root root 13816 mars 28 19:24 jack_loopback.so > -rw-r--r-- 1 root root 46824 mars 28 19:24 jack_netone.so > -rw-r--r-- 1 root root 34536 mars 28 19:24 jack_net.so > -rw-r--r-- 1 root root 34600 mars 28 19:24 netadapter.so > -rw-r--r-- 1 root root 26396 mars 28 19:24 netmanager.so > -rw-r--r-- 1 root root 13860 mars 28 19:24 profiler.so For some reason it seems jack has installed its backends in this location. Jack seems to find them however and the timestamp is recent, so there's probably nothing amiss here. > > > jack is installed /usr/lib/jack: > > > $ ls -l /usr/lib/jack/ > > > total 180 > > > -rwxr-xr-x 1 root root 942 juil. 29 2012 a2j_in.la > > > -rwxr-xr-x 1 root root 59257 juil. 29 2012 a2j_in.so > > > -rwxr-xr-x 1 root root 960 juil. 29 2012 inprocess.la > > > -rwxr-xr-x 1 root root 942 juil. 29 2012 intime.la > > > -rwxr-xr-x 1 root root 1008 juil. 29 2012 jack_alsa.la > > > -rwxr-xr-x 1 root root 1012 juil. 29 2012 jack_alsa_midi.la > > > -rwxr-xr-x 1 root root 85069 juil. 29 2012 jack_alsa_midi.so > > > -rwxr-xr-x 1 root root 992 juil. 29 2012 jack_dummy.la > > > -rwxr-xr-x 1 root root 1060 juil. 29 2012 jack_firewire.la > > > -rwxr-xr-x 1 root root 1000 juil. 29 2012 jack_net.la > > > -rwxr-xr-x 1 root root 980 juil. 29 2012 jack_oss.la I note that the timestamps here are somewhat older than those in the /usr/lib/i386-linux-gnu/jack/ directory. This *may* indicate that they are left over from an earlier install. Then again, the .so files which are here are not present in the other one so there's no overlap. This is interesting, but it seems fairly clear that we don't have an older firewire backend kicking around. Out of interest, did you compile jack yourself? There wouldn't ordinarily be a need to. Regards jonathan |
From: Yves G. <yve...@te...> - 2013-05-28 09:12:33
|
Hi ----- Mail original ----- > De: "Jonathan Woithe" <jw...@ju...> > À: "Yves Grenier" <yve...@te...> > Cc: jw...@ju..., ffa...@li... > Envoyé: Mardi 28 Mai 2013 02:42:19 > Objet: Re: [FFADO-devel] Channels not recognized (Echo Audiofire Pre8 + Ubuntu 12.04) > > Hi Yves > > > > For your information, here's what my development machine is > > > currently > > > giving me for the device that happens to be plugged in at the > > > moment > > > (RME Fireface800): > > > > > > > jack_lsp -A > > > system:capture_1 > > > firewire_pcm:C0_000a350076e71193_cap_analog-1 > > > system:capture_2 > > > firewire_pcm:C1_000a350076e71193_cap_analog-2 > > > > > > And so on. So the port name is "system:*" and the long names are > > > the > > > first > > > alias. > > > > > > > > > I join the result of this command (file jack_lsp.txt) > > > > > > : > > > > > > firewire_pcm:001486059d5c9c6f_Unknown_in > > > > > > system:capture_1 > > > > > > firewire_pcm:001486059d5c9c6f_Unknown0_in > > > > > > system:capture_2 > > > > > > : > > Here's a quick reply - I'm not at my development machine right now > and so I > can't confirm any of this until later today. > > I've been looking at the jack firewire backend code for both jack1 > and > jack2. In jack2, it seems that the port name is constructed with the > following form: > > firewire_pcm:C<i>_<name> > > where <i> is a number which runs from 0 and <name> is the port name > which > comes from ffado. After setting the port name, an alias is created > of the > form > > system:<type>_<n> > > where <type> is either "capture" or "playback", and <n> is a number > running > from 1. A comment in the jack2 code indicates that these aliases are > "jackd1 style port names". This arrangement exactly matches what > you're > seeing from "jack_lsp -A". > > I then look at the current jack1 firewire backend source, and > somewhat > surprisingly it matches jack2 with regard to the port name. However, > it > does not create the "system:*" aliases - at least not explicitly. > This has > me puzzled because clearly on my machine currently I'm seeing > "system:*" > names and "firewire_pcm:*" aliases. The most likely version of jack1 > I'm > running is 0.121.3 (the last release); I've checked that source code > and it > matches the current code in this respect. > > Putting all this together, it seems at face value that what you're > seeing as > jack port names is what the jack2 code intends. I am completely > mystified > as to why I'm not seeing the same thing omn jack1 given that jack1's > code > appears to be doing the same thing - this is something I'm going to > have to > investigate further when I'm back at my development PC. The only > thing I > can think of presently is that jack1 forces the "system:*" name and > moves > any user-specified name to the first alias. > > Another thing that this shows is that my recollection of the history > about > the naming convention of ffado jack ports is in error. I will have > to go > through the list archives to discover the truth. > > Assuming that the above analysis is correct and that there's nothing > erroneous going on, the obvious question in your case is why all the > channels are labelled as "unknown". These names are obtained from > the > device itself via the generic AVC layer, and if this fails "unknown" > is used > as a place holder. Given that these long names were hidden from you > on the > previous system (probaby due to a change in the port naming > convention) it's > possible that ffado has never been able to determine the AudioFile > names on > your device. It's only now, due to the explicit exposure of those > port > names by jack2, that it's noticeable. If this is the case it would > certainly be good to identify the problem and fix it. > > > > Ok. What's > > > > > > ls -la /usr/lib/i386-linux-gnu/jack/ > > > > > > give you? > > > > $ ls -la /usr/lib/i386-linux-gnu/jack/ > > total 444 > > drwxr-xr-x 2 root root 4096 mai 14 10:25 . > > drwxr-xr-x 64 root root 61440 mai 22 08:26 .. > > -rw-r--r-- 1 root root 38724 mars 28 19:24 audioadapter.so > > -rw-r--r-- 1 root root 5432 mars 28 19:24 inprocess.so > > -rw-r--r-- 1 root root 97052 mars 28 19:24 jack_alsa.so > > -rw-r--r-- 1 root root 13816 mars 28 19:24 jack_dummy.so > > -rw-r--r-- 1 root root 34512 mars 28 19:24 jack_firewire.so > > -rw-r--r-- 1 root root 13816 mars 28 19:24 jack_loopback.so > > -rw-r--r-- 1 root root 46824 mars 28 19:24 jack_netone.so > > -rw-r--r-- 1 root root 34536 mars 28 19:24 jack_net.so > > -rw-r--r-- 1 root root 34600 mars 28 19:24 netadapter.so > > -rw-r--r-- 1 root root 26396 mars 28 19:24 netmanager.so > > -rw-r--r-- 1 root root 13860 mars 28 19:24 profiler.so > > For some reason it seems jack has installed its backends in this > location. > Jack seems to find them however and the timestamp is recent, so > there's > probably nothing amiss here. > > > > > jack is installed /usr/lib/jack: > > > > $ ls -l /usr/lib/jack/ > > > > total 180 > > > > -rwxr-xr-x 1 root root 942 juil. 29 2012 a2j_in.la > > > > -rwxr-xr-x 1 root root 59257 juil. 29 2012 a2j_in.so > > > > -rwxr-xr-x 1 root root 960 juil. 29 2012 inprocess.la > > > > -rwxr-xr-x 1 root root 942 juil. 29 2012 intime.la > > > > -rwxr-xr-x 1 root root 1008 juil. 29 2012 jack_alsa.la > > > > -rwxr-xr-x 1 root root 1012 juil. 29 2012 jack_alsa_midi.la > > > > -rwxr-xr-x 1 root root 85069 juil. 29 2012 jack_alsa_midi.so > > > > -rwxr-xr-x 1 root root 992 juil. 29 2012 jack_dummy.la > > > > -rwxr-xr-x 1 root root 1060 juil. 29 2012 jack_firewire.la > > > > -rwxr-xr-x 1 root root 1000 juil. 29 2012 jack_net.la > > > > -rwxr-xr-x 1 root root 980 juil. 29 2012 jack_oss.la > > I note that the timestamps here are somewhat older than those in the > /usr/lib/i386-linux-gnu/jack/ directory. This *may* indicate that > they are > left over from an earlier install. Then again, the .so files which > are here > are not present in the other one so there's no overlap. This is > interesting, but it seems fairly clear that we don't have an older > firewire > backend kicking around. > > Out of interest, did you compile jack yourself? There wouldn't > ordinarily > be a need to. Yes it seems that I compiled jack on this machine, I used revision 4778. I agree with you that there was no need for that, but I do not remember the reason for which I tried it. I could try to clean this. Regards Yves > > Regards > jonathan > |
From: Jonathan W. <jw...@ju...> - 2013-05-28 12:29:33
|
Hi Yves Earlier today I wrote: > For your information, here's what my development machine is > currently giving me for the device that happens to be plugged in at > the moment (RME Fireface800): > > jack_lsp -A > system:capture_1 > firewire_pcm:C0_000a350076e71193_cap_analog-1 > system:capture_2 > firewire_pcm:C1_000a350076e71193_cap_analog-2 > > And so on. So the port name is "system:*" and the long names are > the first alias. : > > I join the result of this command (file jack_lsp.txt) > > : > > firewire_pcm:001486059d5c9c6f_Unknown_in > > system:capture_1 > > firewire_pcm:001486059d5c9c6f_Unknown0_in > > system:capture_2 > > : > I've been looking at the jack firewire backend code for both jack1 and > jack2. In jack2, it seems that the port name is constructed with the > following form: > > firewire_pcm:C<i>_<name> > > where <i> is a number which runs from 0 and <name> is the port name which > comes from ffado. After setting the port name, an alias is created of the > form > > system:<type>_<n> > > where <type> is either "capture" or "playback", and <n> is a number > running from 1. A comment in the jack2 code indicates that these aliases > are "jackd1 style port names". This arrangement exactly matches what > you're seeing from "jack_lsp -A". : Putting all this together, it seems at > face value that what you're seeing as jack port names is what the jack2 > code intends. I am completely mystified as to why I'm not seeing the same > thing omn jack1 given that jack1's code appears to be doing the same thing > - this is something I'm going to have to investigate further when I'm back > at my development PC. The only thing I can think of presently is that > jack1 forces the "system:*" name and moves any user-specified name to the > first alias. I've done some more digging and that final comment seems to indeed be what's going on. In jackd/engine.c:jack_port_do_register() there are the following comments: if the port belongs to the backend client, do some magic with names use backend's original as an alias, use predefined names followed by code which does just what it says. So although the backends define the port name using the "firewire_pcm" syntax, jackd moves this to an alias and generates a system:* string which is used as the port name from that point on. This explains why I get the "system:*" names on my machine at home: that's precisely what jack1 is set up to do. What I think is the corresponding function in jack2 - JackEngine::PortRegister() - does not appear to do any of this fiddling with names. The name set by the backend is the name the user sees. So all this means that with jack2, what you're seeing is pretty much what is intended these days. Jack1 is different, giving you instead system:* names with those generated by the backend being relegated to aliases. Now we can start to consider why you might be seeing a change in port names. The most obvious suggestion is that perhaps your original system was running jack1 - to this day jack1 gives you exactly what you saw with the older system. Another option is that jack2 was on the older system, and that sometime between the version running then and the 1.9.8 you have now the way it tracked port names was changed. I haven't followed jack2 development all that closely so I'm not sure how feasible that final suggestion is. For the sake of completeness, my development machine is running something reporting jack1 0.122.0. It's a git snapshot from March 2012. With that out the way, we can ponder the fact that ffado does not seem capable of identifying the ports beyond "unknown". Ideally it should be able to parse the AVC information provided by the device and deduce sensible names for each channel. In the absence of any evidence to the contrary I expect that this might always have been a problem with the AF device you have; it's just that until now the extended names were hidden and it wasn't obvious that this was happening. Based on the trace you provided earlier it seems that ffado can't parse the information from the device. This may be due to bugs in ffado's parser, or perhaps echo aren't using the AVC functions in quite the way we expect (maybe they don't even implement the descriptors we're relying on). Debugging this will require an affected device, an understanding of how this information is represented in the AudioFire devices and ideally a copy of the relevant AVC standards. In the mean time, my understanding of jack port aliases is that if you continue to use the "system:*" names they should keep working. Whether the channel order is different due to sorting on the long name (the first of which doesn't have an index as such) remains to be seen. That is to say that "system:capture_1" (for example) may not refer to the same physical connector as it did on the old system. Another option is to utilise jack1, but you may have good reasons for choosing to use jack2. > > Out of interest, did you compile jack yourself? There wouldn't > > ordinarily > > be a need to. > > Yes it seems that I compiled jack on this machine, I used revision 4778. > > I agree with you that there was no need for that, but I do not remember > the reason for which I tried it. I could try to clean this. That's fine. It explains the date stamps in the directory listings provided earlier. Regards jonathan |
From: Yves G. <yve...@te...> - 2013-05-30 06:50:27
|
Hi Jonathan ----- Mail original ----- > De: "Jonathan Woithe" <jw...@ju...> > À: "Yves Grenier" <yve...@te...> > Cc: ffa...@li..., "Jonathan Woithe" <jw...@ju...> > Envoyé: Mardi 28 Mai 2013 14:29:09 > Objet: Re: [FFADO-devel] Channels not recognized (Echo Audiofire Pre8 + Ubuntu 12.04) > > Hi Yves > > Earlier today I wrote: > > For your information, here's what my development machine is > > currently giving me for the device that happens to be plugged in at > > the moment (RME Fireface800): > > > > jack_lsp -A > > system:capture_1 > > firewire_pcm:C0_000a350076e71193_cap_analog-1 > > system:capture_2 > > firewire_pcm:C1_000a350076e71193_cap_analog-2 > > > > And so on. So the port name is "system:*" and the long names are > > the first alias. > : > > > I join the result of this command (file jack_lsp.txt) > > > : > > > firewire_pcm:001486059d5c9c6f_Unknown_in > > > system:capture_1 > > > firewire_pcm:001486059d5c9c6f_Unknown0_in > > > system:capture_2 > > > : > > I've been looking at the jack firewire backend code for both jack1 > > and > > jack2. In jack2, it seems that the port name is constructed with > > the > > following form: > > > > firewire_pcm:C<i>_<name> > > > > where <i> is a number which runs from 0 and <name> is the port name > > which > > comes from ffado. After setting the port name, an alias is created > > of the > > form > > > > system:<type>_<n> > > > > where <type> is either "capture" or "playback", and <n> is a number > > running from 1. A comment in the jack2 code indicates that these > > aliases > > are "jackd1 style port names". This arrangement exactly matches > > what > > you're seeing from "jack_lsp -A". : Putting all this together, it > > seems at > > face value that what you're seeing as jack port names is what the > > jack2 > > code intends. I am completely mystified as to why I'm not seeing > > the same > > thing omn jack1 given that jack1's code appears to be doing the > > same thing > > - this is something I'm going to have to investigate further when > > I'm back > > at my development PC. The only thing I can think of presently is > > that > > jack1 forces the "system:*" name and moves any user-specified name > > to the > > first alias. > > I've done some more digging and that final comment seems to indeed be > what's > going on. In jackd/engine.c:jack_port_do_register() there are the > following > comments: > > if the port belongs to the backend client, do some magic with names > > use backend's original as an alias, use predefined names > > followed by code which does just what it says. So although the > backends > define the port name using the "firewire_pcm" syntax, jackd moves > this to an > alias and generates a system:* string which is used as the port name > from > that point on. This explains why I get the "system:*" names on my > machine > at home: that's precisely what jack1 is set up to do. > > What I think is the corresponding function in jack2 - > JackEngine::PortRegister() - does not appear to do any of this > fiddling with > names. The name set by the backend is the name the user sees. > > So all this means that with jack2, what you're seeing is pretty much > what is > intended these days. Jack1 is different, giving you instead system:* > names > with those generated by the backend being relegated to aliases. > > Now we can start to consider why you might be seeing a change in port > names. > The most obvious suggestion is that perhaps your original system was > running > jack1 - to this day jack1 gives you exactly what you saw with the > older > system. Another option is that jack2 was on the older system, and > that > sometime between the version running then and the 1.9.8 you have now > the way it tracked port names was changed. I haven't followed jack2 > development all that closely so I'm not sure how feasible that final > suggestion is. I agree with you, the change in the name port happens during the transition from jack1 to jack2. I had observed it on another machine to which I connect a Saffire Pro 24. > > For the sake of completeness, my development machine is running > something > reporting jack1 0.122.0. It's a git snapshot from March 2012. > > With that out the way, we can ponder the fact that ffado does not > seem > capable of identifying the ports beyond "unknown". Ideally it should > be > able to parse the AVC information provided by the device and deduce > sensible > names for each channel. In the absence of any evidence to the > contrary I > expect that this might always have been a problem with the AF device > you > have; it's just that until now the extended names were hidden and it > wasn't > obvious that this was happening. Based on the trace you provided > earlier it > seems that ffado can't parse the information from the device. This > may be > due to bugs in ffado's parser, or perhaps echo aren't using the AVC > functions in quite the way we expect (maybe they don't even implement > the > descriptors we're relying on). Debugging this will require an > affected > device, an understanding of how this information is represented in > the > AudioFire devices and ideally a copy of the relevant AVC standards. I also agree with your analysis: the bug may have been present earlier and only appear due to the change in the way jack names the channels. Tell me if there is a way I can help debugging. > > In the mean time, my understanding of jack port aliases is that if > you > continue to use the "system:*" names they should keep working. > Whether the > channel order is different due to sorting on the long name (the first > of > which doesn't have an index as such) remains to be seen. That is to > say > that "system:capture_1" (for example) may not refer to the same > physical > connector as it did on the old system. Another option is to utilise > jack1, but you may have good reasons for choosing to use jack2. I confirm that if I use the "system:*" names, it continues to work. For instance, I use meterbridge without any problem. The problem appear with "ffado-test Discover", and with the connection list in qjackctl, mainly because the "Unknown*" names are not ordered correctly. > > > > Out of interest, did you compile jack yourself? There wouldn't > > > ordinarily > > > be a need to. > > > > Yes it seems that I compiled jack on this machine, I used revision > > 4778. > > > > I agree with you that there was no need for that, but I do not > > remember > > the reason for which I tried it. I could try to clean this. > > That's fine. It explains the date stamps in the directory listings > provided > earlier. I cleaned the files, and reinstalled jackd2 in the version provided with unubtu 12.04. As expected, it does bring any improvement to the above problem. Best regards Yves > > Regards > jonathan > |