From: Takashi S. <o-t...@sa...> - 2013-10-14 03:17:44
|
Hi all, This is a call for testing my ALSA driver for Fireworks/BeBoB based devices. Please test 'snd-fireworks' for Fireworks and 'snd-bebob' for BeBoB if you have some devices listed in the end of this mail. Status: - still under development - Without snd-dice and Clemens' development (I must do this later) Functionality: - playback/capturing (full duplex) with PCM/MIDI interface - hardware metering for some devices with CONTROL interface - switching clock source/digital interface/digital mode with CONTROL interface - print hardware status with PROC interface Note: - Don't use simultaneously 'ALSA PCM/MIDI playback/capture' and 'jackd with Firewire (FFADO) backend'. Both of them try connecting to the device when another is running. - I add much modification into snd-firewire-lib for full duplex synchronization of receive/transmit AMDTP stream. Requirement: - Linux kernel 3.11 or later because of Juju (nickname of Firewire stack) changing its API. - Dynamic Kernel Module Support (DKMS) is reccomended for safely installing/uninstalling (I work with Ubuntu 13.10) Bug report: - report with /proc/asound/cardX/#XXX - please send your experiences to me with the output How to install (DKMS): 1. $ git clone https://github.com/takaswie/snd-firewire-improve.git 2. $ ln -s $(pwd)/snd-firewire-improve/ /usr/src/alsa-firewire-3.11 (superuser) 3. $ dkms install snd-firewire/3.11 (superuser) How to uninstall (DKMS): 1. $ modprobe -r snd-bebob snd-fireworks snd-firewire-lib (superuser) 2. $ dkms remove ans-firewire/3.11 --all (superuser) 3. $ rm /usr/src/alsa-firewire-3.11 (superuser) 4. $ rm snd-firewire-improve How to install (Manual): 1. $ git clone https://github.com/takaswie/snd-firewire-improve.git 2. $ cd snd-firewire-improve 3. $ make 4, backup system snd-firewire-lib/snd-firewire-speakers/snd-isight (superuser) 5. install snd-firewire-lib/snd-firewire-speakers/snd-isight/snd-fireworks/snd-bebob (superuser) 6. depmod -a (superuser) How to uninstall (Manual) 1. modprobe -r snd-firewire-lib snd-firewire-speakers snd-isight snd-fireworks snd-bebob (superuser) 2. remove snd-firewire-lib/snd-firewire-speakers/snd-isight/snd-fireworks/snd-bebob (superuser) 3. recover snd-firewire-lib/snd-firewire-speakers/snd-isight (superuser) 4. depmod -a (superuser) Confirmed to work: - AudioFire4 - AudioFirePre8 - Ozonic - Firewire Solo - Firewire Audiophile - Firewire 410 == Fireworks based devices [Echo Audio] AudioFire2 AudioFire4 AudioFirePre8 AudioFire8 (till 2009) AudioFire8 (since 2009) AudioFire12 [Gibson] RIP [Mackie] Onyx 400F Onyx 1200F == BeBoB based devices [Yamaha] GO44 GO46 [M-Audio] (to control mixer channels please use FFADO upstream) Ozonic Firewire 410 Firewire Audiophile Firewire Solo NRV10 ProFireLightbridge [Focusrite] SaffirePro 26 I/O SaffirePro 10 I/O Saffire(LE) [Edirol] FA-66 FA-101 [TerraTecElectronic GmbH] Phase88FW PhaseX24FW [PreSonus] FireBox FirePod [Mackie] OnyxFirewire [Tascam] IF-FW/DM [Behringer] X32 [ApogeeElectronics] Rosetta200 [ESI] Quatafire610 Regards Takashi Sakamoto o-t...@sa... |
From: Michael M. <mih...@ya...> - 2014-01-05 13:29:02
|
Hi Takashi, I have tested your driver with FW1814 on Linux kernel 3.11.5 installed on Linux Mint 15 and have found following issues so far 1. snd-bebob is not build. It seams dkms.conf contains error. Here is my patch to workaround the problem. I'm not familiar with DKMS builds so I may be wrong diff --git a/dkms.conf b/dkms.conf index 888ec71..06e9123 100644 --- a/dkms.conf +++ b/dkms.conf @@ -12,7 +12,7 @@ BUILT_MODULE_LOCATION[3]="./sound/firewire" BUILT_MODULE_LOCATION[4]="./sound/firewire" BUILT_MODULE_LOCATION[5]="./sound/firewire/fireworks" BUILT_MODULE_LOCATION[6]="./sound/firewire/bebob" -BUILT_MODULE_LOCATION[6]="./sound/firewire/oxfw" +BUILT_MODULE_LOCATION[7]="./sound/firewire/oxfw" BUILT_MODULE_NAME[0]="snd-firewire-lib" BUILT_MODULE_NAME[1]="snd-firewire-speakers" @@ -21,7 +21,7 @@ BUILT_MODULE_NAME[3]="snd-scs1x" BUILT_MODULE_NAME[4]="snd-dice" BUILT_MODULE_NAME[5]="snd-fireworks" BUILT_MODULE_NAME[6]="snd-bebob" -BUILT_MODULE_NAME[6]="snd-oxfw" +BUILT_MODULE_NAME[7]="snd-oxfw" DEST_MODULE_LOCATION[0]="/updates/dkms/" DEST_MODULE_LOCATION[1]="/updates/dkms/" @@ -30,6 +30,6 @@ DEST_MODULE_LOCATION[3]="/updates/dkms/" DEST_MODULE_LOCATION[4]="/updates/dkms/" DEST_MODULE_LOCATION[5]="/updates/dkms/" DEST_MODULE_LOCATION[6]="/updates/dkms/" -DEST_MODULE_LOCATION[6]="/updates/dkms/" +DEST_MODULE_LOCATION[7]="/updates/dkms/" AUTOINSTALL="yes" 2. I can see F1814 sound card under /proc/asound however KDE reports after some time that the device has been remover. Here is the kernel messages Jan 5 17:05:57 kirogaz kernel: [ 2244.554306] firewire_core 0000:09:00.0: created device fw1: GUID 000d6c0410ebdb45, S400 Jan 5 17:05:57 kirogaz kernel: [ 2244.554310] firewire_core 0000:09:00.0: phy config: new root=ffc0, gap_count=5 Jan 5 17:06:00 kirogaz kernel: [ 2247.658545] firewire_core 0000:09:00.0: phy config: new root=ffc1, gap_count=5 Jan 5 17:06:11 kirogaz kernel: [ 2258.175114] snd-bebob fw1.0: failed to initialize clock params Jan 5 17:06:11 kirogaz kernel: [ 2258.188055] firewire_core 0000:09:00.0: refreshed device fw1 Jan 5 17:06:20 kirogaz kernel: [ 2267.912554] snd-bebob fw1.0: isochronous resource deallocation failed Jan 5 17:06:27 kirogaz kernel: [ 2275.085005] snd-bebob fw1.0: transaction failed: no ack Jan 5 17:07:32 kirogaz kernel: [ 2339.395214] firewire_core 0000:09:00.0: phy config: new root=ffc1, gap_count=5 Jan 5 17:07:32 kirogaz kernel: [ 2339.853183] firewire_core 0000:09:00.0: created device fw1: GUID 000d6c0410ebdb45, S400 Jan 5 17:07:35 kirogaz kernel: [ 2343.009477] firewire_core 0000:09:00.0: phy config: new root=ffc1, gap_count=5 Jan 5 17:07:41 kirogaz kernel: [ 2348.520553] snd-bebob fw1.0: failed to initialize clock params Jan 5 17:07:43 kirogaz kernel: [ 2350.556563] firewire_core 0000:09:00.0: refreshed device fw1 Jan 5 17:08:33 kirogaz kernel: [ 2400.145899] snd-bebob fw1.0: iPCR0: plug is already in use Jan 5 17:08:33 kirogaz kernel: [ 2400.370598] snd-bebob fw1.0: iPCR0: plug is already in use Jan 5 17:08:44 kirogaz kernel: [ 2411.844333] snd-bebob fw1.0: iPCR0: plug is already in use Jan 5 17:08:47 kirogaz kernel: [ 2414.193002] snd-bebob fw1.0: iPCR0: plug is already in use Jan 5 17:08:47 kirogaz kernel: [ 2414.815634] snd-bebob fw1.0: iPCR0: plug is already in use Jan 5 17:08:50 kirogaz kernel: [ 2417.249864] snd-bebob fw1.0: iPCR0: plug is already in use Jan 5 17:08:50 kirogaz kernel: [ 2417.875256] snd-bebob fw1.0: iPCR0: plug is already in use Jan 5 17:08:51 kirogaz kernel: [ 2418.178726] snd-bebob fw1.0: iPCR0: plug is already in use I do not have FFADO or JACK installed except my working copy in a sandbox so they do not started automatically Modules are loaded snd_bebob 40872 0 snd_firewire_lib 29430 1 snd_bebob Here is the contents of some useful files. The strange here is clock freq Sampling rate: 176400 Clock Source: Internal with Digital Mute cat cards 0 [PCH ]: HDA-Intel - HDA Intel PCH HDA Intel PCH at 0xfbf20000 irq 84 1 [F1814 ]: BeBoB - FW 1814 M-AUDIO FW 1814 (id:131, rev:1), GUID 000d6c0400ebdb45 at fw1.0, S400 2 [HDMI ]: HDA-Intel - HDA ATI HDMI HDA ATI HDMI at 0xfbe60000 irq 85 3 [Adapter ]: USB-Audio - Rocksmith USB Guitar Adapter Hercules Rocksmith USB Guitar Adapter at usb-0000:00:1d.0-1.5, full speed find . -type f -exec cat {} \; F1814 Manufacturer: bridgeCo Protocol Ver: 1 Build Ver: 0 GUID: 0x000D6C0400EBDB45 Model ID: 0x83 Model Rev: 1 Firmware Date: 20070713 Firmware Time: 080440 Firmware ID: 0x0 Firmware Ver: 0 Base Addr: 0x20080000 Max Size: 1572864 Loader Date: 20040330 Loader Time: 025909 Output Stream from device: Rate PCM MIDI 22050 0 0 24000 0 0 32000 0 0 44100 10 1 48000 10 1 88200 10 1 96000 10 1 176400 2 1 192000 2 1 Input Stream to device: Rate PCM MIDI 22050 0 0 24000 0 0 32000 0 0 44100 6 1 48000 6 1 88200 6 1 96000 6 1 176400 4 1 192000 4 1 Sampling rate: 176400 Clock Source: Internal with Digital Mute Analog In 1: 0 Analog In 2: 0 Analog In 3: 0 Analog In 4: 0 Analog In 5: 0 Analog In 6: 0 Analog In 7: 0 Analog In 8: 0 S/PDIF In 1: 0 S/PDIF In 2: 0 ADAT In 1: 0 ADAT In 2: 0 ADAT In 3: 0 ADAT In 4: 0 ADAT In 5: 0 ADAT In 6: 0 ADAT In 7: 0 ADAT In 8: 0 Analog Out 1: 0 Analog Out 2: 0 Analog Out 3: 0 Analog Out 4: 0 S/PDIF Out 1: 0 S/PDIF Out 2: 0 ADAT Out 1: 0 ADAT Out 2: 0 ADAT Out 3: 0 ADAT Out 4: 0 ADAT Out 5: 0 ADAT Out 6: 0 ADAT Out 7: 0 ADAT Out 8: 0 HP Out 1: 0 HP Out 2: 0 HP Out 3: 0 HP Out 4: 0 Aux Out 1: 0 Aux Out 2: 0 FW 1814 MIDI Output 0 Tx bytes : 0 Input 0 Rx bytes : 0 closed closed closed card: 1 device: 0 subdevice: 0 stream: CAPTURE id: BeBoB name: FW 1814 PCM subname: subdevice #0 class: 0 subclass: 0 subdevices_count: 1 subdevices_avail: 1 0 card: 1 device: 0 subdevice: 0 stream: CAPTURE id: BeBoB name: FW 1814 PCM subname: subdevice #0 class: 0 subclass: 0 subdevices_count: 1 subdevices_avail: 1 closed closed closed card: 1 device: 0 subdevice: 0 stream: PLAYBACK id: BeBoB name: FW 1814 PCM subname: subdevice #0 class: 0 subclass: 0 subdevices_count: 1 subdevices_avail: 1 0 card: 1 device: 0 subdevice: 0 stream: PLAYBACK id: BeBoB name: FW 1814 PCM subname: subdevice #0 class: 0 subclass: 0 subdevices_count: 1 subdevices_avail: 1 BR, Michael > Hi all, > > This is a call for testing my ALSA driver for Fireworks/BeBoB based devices. > > Please test 'snd-fireworks' for Fireworks and 'snd-bebob' for BeBoB if > you have some devices listed in the end of this mail. > > Status: > - still under development > - Without snd-dice and Clemens' development (I must do this later) > > Functionality: > - playback/capturing (full duplex) with PCM/MIDI interface > - hardware metering for some devices with CONTROL interface > - switching clock source/digital interface/digital mode with CONTROL > interface > - print hardware status with PROC interface > > Note: > - Don't use simultaneously 'ALSA PCM/MIDI playback/capture' and 'jackd > with Firewire (FFADO) backend'. Both of them try connecting to the > device when another is running. > - I add much modification into snd-firewire-lib for full duplex > synchronization of receive/transmit AMDTP stream. > > Requirement: > - Linux kernel 3.11 or later because of Juju (nickname of Firewire > stack) changing its API. > - Dynamic Kernel Module Support (DKMS) is reccomended for safely > installing/uninstalling > (I work with Ubuntu 13.10) > > Bug report: > - report with /proc/asound/cardX/#XXX > - please send your experiences to me with the output > > How to install (DKMS): > 1. $ git clone https://github.com/takaswie/snd-firewire-improve.git > 2. $ ln -s $(pwd)/snd-firewire-improve/ /usr/src/alsa-firewire-3.11 > (superuser) > 3. $ dkms install snd-firewire/3.11 (superuser) > > How to uninstall (DKMS): > 1. $ modprobe -r snd-bebob snd-fireworks snd-firewire-lib (superuser) > 2. $ dkms remove ans-firewire/3.11 --all (superuser) > 3. $ rm /usr/src/alsa-firewire-3.11 (superuser) > 4. $ rm snd-firewire-improve > > How to install (Manual): > 1. $ git clone https://github.com/takaswie/snd-firewire-improve.git > 2. $ cd snd-firewire-improve > 3. $ make > 4, backup system snd-firewire-lib/snd-firewire-speakers/snd-isight > (superuser) > 5. install > snd-firewire-lib/snd-firewire-speakers/snd-isight/snd-fireworks/snd-bebob (superuser) > 6. depmod -a (superuser) > > How to uninstall (Manual) > 1. modprobe -r snd-firewire-lib snd-firewire-speakers snd-isight > snd-fireworks snd-bebob (superuser) > 2. remove > snd-firewire-lib/snd-firewire-speakers/snd-isight/snd-fireworks/snd-bebob (superuser) > 3. recover snd-firewire-lib/snd-firewire-speakers/snd-isight (superuser) > 4. depmod -a (superuser) > > Confirmed to work: > - AudioFire4 > - AudioFirePre8 > - Ozonic > - Firewire Solo > - Firewire Audiophile > - Firewire 410 > > == Fireworks based devices > [Echo Audio] > AudioFire2 > AudioFire4 > AudioFirePre8 > AudioFire8 (till 2009) > AudioFire8 (since 2009) > AudioFire12 > > [Gibson] > RIP > > [Mackie] > Onyx 400F > Onyx 1200F > > == BeBoB based devices > [Yamaha] > GO44 > GO46 > > [M-Audio] > (to control mixer channels please use FFADO upstream) > Ozonic > Firewire 410 > Firewire Audiophile > Firewire Solo > NRV10 > ProFireLightbridge > > [Focusrite] > SaffirePro 26 I/O > SaffirePro 10 I/O > Saffire(LE) > > [Edirol] > FA-66 > FA-101 > > [TerraTecElectronic GmbH] > Phase88FW > PhaseX24FW > > [PreSonus] > FireBox > FirePod > > [Mackie] > OnyxFirewire > > [Tascam] > IF-FW/DM > > [Behringer] > X32 > > [ApogeeElectronics] > Rosetta200 > > [ESI] > Quatafire610 > > > Regards > > Takashi Sakamoto > o-t...@sa... > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk > _______________________________________________ > FFADO-devel mailing list > FFA...@li... > https://lists.sourceforge.net/lists/listinfo/ffado-devel |
From: Michael M. <mih...@ya...> - 2014-01-05 15:47:20
|
I have some update. I tried aplay command to play sample WAV files through FW1814 and can see some activity on the card like pops and clicks and sometimes I can see the green led indicating that there is an output. Takashi, could you please share the test procedure you are using? BR, Michael > Hi Takashi, > > I have tested your driver with FW1814 on Linux kernel 3.11.5 installed > on Linux Mint 15 and have found following issues so far > > 1. snd-bebob is not build. It seams dkms.conf contains error. Here is my > patch to workaround the problem. I'm not familiar with DKMS builds so I > may be wrong > > diff --git a/dkms.conf b/dkms.conf > index 888ec71..06e9123 100644 > --- a/dkms.conf > +++ b/dkms.conf > @@ -12,7 +12,7 @@ BUILT_MODULE_LOCATION[3]="./sound/firewire" > BUILT_MODULE_LOCATION[4]="./sound/firewire" > BUILT_MODULE_LOCATION[5]="./sound/firewire/fireworks" > BUILT_MODULE_LOCATION[6]="./sound/firewire/bebob" > -BUILT_MODULE_LOCATION[6]="./sound/firewire/oxfw" > +BUILT_MODULE_LOCATION[7]="./sound/firewire/oxfw" > > BUILT_MODULE_NAME[0]="snd-firewire-lib" > BUILT_MODULE_NAME[1]="snd-firewire-speakers" > @@ -21,7 +21,7 @@ BUILT_MODULE_NAME[3]="snd-scs1x" > BUILT_MODULE_NAME[4]="snd-dice" > BUILT_MODULE_NAME[5]="snd-fireworks" > BUILT_MODULE_NAME[6]="snd-bebob" > -BUILT_MODULE_NAME[6]="snd-oxfw" > +BUILT_MODULE_NAME[7]="snd-oxfw" > > DEST_MODULE_LOCATION[0]="/updates/dkms/" > DEST_MODULE_LOCATION[1]="/updates/dkms/" > @@ -30,6 +30,6 @@ DEST_MODULE_LOCATION[3]="/updates/dkms/" > DEST_MODULE_LOCATION[4]="/updates/dkms/" > DEST_MODULE_LOCATION[5]="/updates/dkms/" > DEST_MODULE_LOCATION[6]="/updates/dkms/" > -DEST_MODULE_LOCATION[6]="/updates/dkms/" > +DEST_MODULE_LOCATION[7]="/updates/dkms/" > > AUTOINSTALL="yes" > > 2. I can see F1814 sound card under /proc/asound however KDE reports > after some time that the device has been remover. Here is the kernel > messages > > Jan 5 17:05:57 kirogaz kernel: [ 2244.554306] firewire_core > 0000:09:00.0: created device fw1: GUID 000d6c0410ebdb45, S400 > Jan 5 17:05:57 kirogaz kernel: [ 2244.554310] firewire_core > 0000:09:00.0: phy config: new root=ffc0, gap_count=5 > Jan 5 17:06:00 kirogaz kernel: [ 2247.658545] firewire_core > 0000:09:00.0: phy config: new root=ffc1, gap_count=5 > Jan 5 17:06:11 kirogaz kernel: [ 2258.175114] snd-bebob fw1.0: failed > to initialize clock params > Jan 5 17:06:11 kirogaz kernel: [ 2258.188055] firewire_core > 0000:09:00.0: refreshed device fw1 > Jan 5 17:06:20 kirogaz kernel: [ 2267.912554] snd-bebob fw1.0: > isochronous resource deallocation failed > Jan 5 17:06:27 kirogaz kernel: [ 2275.085005] snd-bebob fw1.0: > transaction failed: no ack > Jan 5 17:07:32 kirogaz kernel: [ 2339.395214] firewire_core > 0000:09:00.0: phy config: new root=ffc1, gap_count=5 > Jan 5 17:07:32 kirogaz kernel: [ 2339.853183] firewire_core > 0000:09:00.0: created device fw1: GUID 000d6c0410ebdb45, S400 > Jan 5 17:07:35 kirogaz kernel: [ 2343.009477] firewire_core > 0000:09:00.0: phy config: new root=ffc1, gap_count=5 > Jan 5 17:07:41 kirogaz kernel: [ 2348.520553] snd-bebob fw1.0: failed > to initialize clock params > Jan 5 17:07:43 kirogaz kernel: [ 2350.556563] firewire_core > 0000:09:00.0: refreshed device fw1 > Jan 5 17:08:33 kirogaz kernel: [ 2400.145899] snd-bebob fw1.0: iPCR0: > plug is already in use > Jan 5 17:08:33 kirogaz kernel: [ 2400.370598] snd-bebob fw1.0: iPCR0: > plug is already in use > Jan 5 17:08:44 kirogaz kernel: [ 2411.844333] snd-bebob fw1.0: iPCR0: > plug is already in use > Jan 5 17:08:47 kirogaz kernel: [ 2414.193002] snd-bebob fw1.0: iPCR0: > plug is already in use > Jan 5 17:08:47 kirogaz kernel: [ 2414.815634] snd-bebob fw1.0: iPCR0: > plug is already in use > Jan 5 17:08:50 kirogaz kernel: [ 2417.249864] snd-bebob fw1.0: iPCR0: > plug is already in use > Jan 5 17:08:50 kirogaz kernel: [ 2417.875256] snd-bebob fw1.0: iPCR0: > plug is already in use > Jan 5 17:08:51 kirogaz kernel: [ 2418.178726] snd-bebob fw1.0: iPCR0: > plug is already in use > > I do not have FFADO or JACK installed except my working copy in a > sandbox so they do not started automatically > > Modules are loaded > > snd_bebob 40872 0 > snd_firewire_lib 29430 1 snd_bebob > > Here is the contents of some useful files. The strange here is clock freq > > Sampling rate: 176400 > Clock Source: Internal with Digital Mute > > cat cards > 0 [PCH ]: HDA-Intel - HDA Intel PCH > HDA Intel PCH at 0xfbf20000 irq 84 > 1 [F1814 ]: BeBoB - FW 1814 > M-AUDIO FW 1814 (id:131, rev:1), GUID > 000d6c0400ebdb45 at fw1.0, S400 > 2 [HDMI ]: HDA-Intel - HDA ATI HDMI > HDA ATI HDMI at 0xfbe60000 irq 85 > 3 [Adapter ]: USB-Audio - Rocksmith USB Guitar Adapter > Hercules Rocksmith USB Guitar Adapter at > usb-0000:00:1d.0-1.5, full speed > > > find . -type f -exec cat {} \; > F1814 > Manufacturer: bridgeCo > Protocol Ver: 1 > Build Ver: 0 > GUID: 0x000D6C0400EBDB45 > Model ID: 0x83 > Model Rev: 1 > Firmware Date: 20070713 > Firmware Time: 080440 > Firmware ID: 0x0 > Firmware Ver: 0 > Base Addr: 0x20080000 > Max Size: 1572864 > Loader Date: 20040330 > Loader Time: 025909 > Output Stream from device: > Rate PCM MIDI > 22050 0 0 > 24000 0 0 > 32000 0 0 > 44100 10 1 > 48000 10 1 > 88200 10 1 > 96000 10 1 > 176400 2 1 > 192000 2 1 > Input Stream to device: > Rate PCM MIDI > 22050 0 0 > 24000 0 0 > 32000 0 0 > 44100 6 1 > 48000 6 1 > 88200 6 1 > 96000 6 1 > 176400 4 1 > 192000 4 1 > Sampling rate: 176400 > Clock Source: Internal with Digital Mute > Analog In 1: 0 > Analog In 2: 0 > Analog In 3: 0 > Analog In 4: 0 > Analog In 5: 0 > Analog In 6: 0 > Analog In 7: 0 > Analog In 8: 0 > S/PDIF In 1: 0 > S/PDIF In 2: 0 > ADAT In 1: 0 > ADAT In 2: 0 > ADAT In 3: 0 > ADAT In 4: 0 > ADAT In 5: 0 > ADAT In 6: 0 > ADAT In 7: 0 > ADAT In 8: 0 > Analog Out 1: 0 > Analog Out 2: 0 > Analog Out 3: 0 > Analog Out 4: 0 > S/PDIF Out 1: 0 > S/PDIF Out 2: 0 > ADAT Out 1: 0 > ADAT Out 2: 0 > ADAT Out 3: 0 > ADAT Out 4: 0 > ADAT Out 5: 0 > ADAT Out 6: 0 > ADAT Out 7: 0 > ADAT Out 8: 0 > HP Out 1: 0 > HP Out 2: 0 > HP Out 3: 0 > HP Out 4: 0 > Aux Out 1: 0 > Aux Out 2: 0 > FW 1814 MIDI > > Output 0 > Tx bytes : 0 > Input 0 > Rx bytes : 0 > closed > closed > closed > card: 1 > device: 0 > subdevice: 0 > stream: CAPTURE > id: BeBoB > name: FW 1814 PCM > subname: subdevice #0 > class: 0 > subclass: 0 > subdevices_count: 1 > subdevices_avail: 1 > 0 > card: 1 > device: 0 > subdevice: 0 > stream: CAPTURE > id: BeBoB > name: FW 1814 PCM > subname: subdevice #0 > class: 0 > subclass: 0 > subdevices_count: 1 > subdevices_avail: 1 > closed > closed > closed > card: 1 > device: 0 > subdevice: 0 > stream: PLAYBACK > id: BeBoB > name: FW 1814 PCM > subname: subdevice #0 > class: 0 > subclass: 0 > subdevices_count: 1 > subdevices_avail: 1 > 0 > card: 1 > device: 0 > subdevice: 0 > stream: PLAYBACK > id: BeBoB > name: FW 1814 PCM > subname: subdevice #0 > class: 0 > subclass: 0 > subdevices_count: 1 > subdevices_avail: 1 > > > BR, > Michael > > > > > > > >> Hi all, >> >> This is a call for testing my ALSA driver for Fireworks/BeBoB based devices. >> >> Please test 'snd-fireworks' for Fireworks and 'snd-bebob' for BeBoB if >> you have some devices listed in the end of this mail. >> >> Status: >> - still under development >> - Without snd-dice and Clemens' development (I must do this later) >> >> Functionality: >> - playback/capturing (full duplex) with PCM/MIDI interface >> - hardware metering for some devices with CONTROL interface >> - switching clock source/digital interface/digital mode with CONTROL >> interface >> - print hardware status with PROC interface >> >> Note: >> - Don't use simultaneously 'ALSA PCM/MIDI playback/capture' and 'jackd >> with Firewire (FFADO) backend'. Both of them try connecting to the >> device when another is running. >> - I add much modification into snd-firewire-lib for full duplex >> synchronization of receive/transmit AMDTP stream. >> >> Requirement: >> - Linux kernel 3.11 or later because of Juju (nickname of Firewire >> stack) changing its API. >> - Dynamic Kernel Module Support (DKMS) is reccomended for safely >> installing/uninstalling >> (I work with Ubuntu 13.10) >> >> Bug report: >> - report with /proc/asound/cardX/#XXX >> - please send your experiences to me with the output >> >> How to install (DKMS): >> 1. $ git clone https://github.com/takaswie/snd-firewire-improve.git >> 2. $ ln -s $(pwd)/snd-firewire-improve/ /usr/src/alsa-firewire-3.11 >> (superuser) >> 3. $ dkms install snd-firewire/3.11 (superuser) >> >> How to uninstall (DKMS): >> 1. $ modprobe -r snd-bebob snd-fireworks snd-firewire-lib (superuser) >> 2. $ dkms remove ans-firewire/3.11 --all (superuser) >> 3. $ rm /usr/src/alsa-firewire-3.11 (superuser) >> 4. $ rm snd-firewire-improve >> >> How to install (Manual): >> 1. $ git clone https://github.com/takaswie/snd-firewire-improve.git >> 2. $ cd snd-firewire-improve >> 3. $ make >> 4, backup system snd-firewire-lib/snd-firewire-speakers/snd-isight >> (superuser) >> 5. install >> snd-firewire-lib/snd-firewire-speakers/snd-isight/snd-fireworks/snd-bebob (superuser) >> 6. depmod -a (superuser) >> >> How to uninstall (Manual) >> 1. modprobe -r snd-firewire-lib snd-firewire-speakers snd-isight >> snd-fireworks snd-bebob (superuser) >> 2. remove >> snd-firewire-lib/snd-firewire-speakers/snd-isight/snd-fireworks/snd-bebob (superuser) >> 3. recover snd-firewire-lib/snd-firewire-speakers/snd-isight (superuser) >> 4. depmod -a (superuser) >> >> Confirmed to work: >> - AudioFire4 >> - AudioFirePre8 >> - Ozonic >> - Firewire Solo >> - Firewire Audiophile >> - Firewire 410 >> >> == Fireworks based devices >> [Echo Audio] >> AudioFire2 >> AudioFire4 >> AudioFirePre8 >> AudioFire8 (till 2009) >> AudioFire8 (since 2009) >> AudioFire12 >> >> [Gibson] >> RIP >> >> [Mackie] >> Onyx 400F >> Onyx 1200F >> >> == BeBoB based devices >> [Yamaha] >> GO44 >> GO46 >> >> [M-Audio] >> (to control mixer channels please use FFADO upstream) >> Ozonic >> Firewire 410 >> Firewire Audiophile >> Firewire Solo >> NRV10 >> ProFireLightbridge >> >> [Focusrite] >> SaffirePro 26 I/O >> SaffirePro 10 I/O >> Saffire(LE) >> >> [Edirol] >> FA-66 >> FA-101 >> >> [TerraTecElectronic GmbH] >> Phase88FW >> PhaseX24FW >> >> [PreSonus] >> FireBox >> FirePod >> >> [Mackie] >> OnyxFirewire >> >> [Tascam] >> IF-FW/DM >> >> [Behringer] >> X32 >> >> [ApogeeElectronics] >> Rosetta200 >> >> [ESI] >> Quatafire610 >> >> >> Regards >> >> Takashi Sakamoto >> o-t...@sa... >> >> ------------------------------------------------------------------------------ >> October Webinars: Code for Performance >> Free Intel webinars can help you accelerate application performance. >> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from >> the latest Intel processors and coprocessors. See abstracts and register > >> http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk >> _______________________________________________ >> FFADO-devel mailing list >> FFA...@li... >> https://lists.sourceforge.net/lists/listinfo/ffado-devel > > ------------------------------------------------------------------------------ > Rapidly troubleshoot problems before they affect your business. Most IT > organizations don't have a clear picture of how application performance > affects their revenue. With AppDynamics, you get 100% visibility into your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk > _______________________________________________ > FFADO-devel mailing list > FFA...@li... > https://lists.sourceforge.net/lists/listinfo/ffado-devel |
From: Michael M. <mih...@ya...> - 2014-01-05 17:18:15
|
I have looked at the code of snd_bebob_maudio_special_discover(struct snd_bebob *bebob, bool is1814) { int err; bebob->maudio_is1814 = is1814; /* initialize these parameters because driver is not allowed to ask */ err = special_clk_set_params(bebob, 0x03, 0x00, 0x00, 0x00); if (err < 0) dev_err(&bebob->unit->device, "failed to initialize clock params\n"); err = avc_audio_get_selector(bebob->unit, 0x00, 0x04, &bebob->dig_in_iface); if (err < 0) dev_err(&bebob->unit->device, "failed to get current dig iface."); err = snd_bebob_maudio_special_add_controls(bebob); if (err < 0) return -EIO; special_stream_formation_set(bebob); if (bebob->maudio_is1814) { bebob->midi_input_ports = 1; bebob->midi_output_ports = 1; } else { bebob->midi_input_ports = 2; bebob->midi_output_ports = 2; } bebob->maudio_special_quirk = true; return 0; } it seams to me there is a bug here. If special_clk_set_params fails but later snd_bebob_maudio_special_add_controls doesn't fail snd_bebob_maudio_special_discover will return 0. The same for avc_audio_get_selector. Was it done by intension? Or just missed 'return -EIO'. It explains why I see ALSA card but the device doesn't really functioning. --Michael > I have some update. I tried aplay command to play sample WAV files > through FW1814 and can see some activity on the card like pops and > clicks and sometimes I can see the green led indicating that there is an > output. > > Takashi, could you please share the test procedure you are using? > > BR, > Michael >> Hi Takashi, >> >> I have tested your driver with FW1814 on Linux kernel 3.11.5 installed >> on Linux Mint 15 and have found following issues so far >> >> 1. snd-bebob is not build. It seams dkms.conf contains error. Here is my >> patch to workaround the problem. I'm not familiar with DKMS builds so I >> may be wrong >> >> diff --git a/dkms.conf b/dkms.conf >> index 888ec71..06e9123 100644 >> --- a/dkms.conf >> +++ b/dkms.conf >> @@ -12,7 +12,7 @@ BUILT_MODULE_LOCATION[3]="./sound/firewire" >> BUILT_MODULE_LOCATION[4]="./sound/firewire" >> BUILT_MODULE_LOCATION[5]="./sound/firewire/fireworks" >> BUILT_MODULE_LOCATION[6]="./sound/firewire/bebob" >> -BUILT_MODULE_LOCATION[6]="./sound/firewire/oxfw" >> +BUILT_MODULE_LOCATION[7]="./sound/firewire/oxfw" >> >> BUILT_MODULE_NAME[0]="snd-firewire-lib" >> BUILT_MODULE_NAME[1]="snd-firewire-speakers" >> @@ -21,7 +21,7 @@ BUILT_MODULE_NAME[3]="snd-scs1x" >> BUILT_MODULE_NAME[4]="snd-dice" >> BUILT_MODULE_NAME[5]="snd-fireworks" >> BUILT_MODULE_NAME[6]="snd-bebob" >> -BUILT_MODULE_NAME[6]="snd-oxfw" >> +BUILT_MODULE_NAME[7]="snd-oxfw" >> >> DEST_MODULE_LOCATION[0]="/updates/dkms/" >> DEST_MODULE_LOCATION[1]="/updates/dkms/" >> @@ -30,6 +30,6 @@ DEST_MODULE_LOCATION[3]="/updates/dkms/" >> DEST_MODULE_LOCATION[4]="/updates/dkms/" >> DEST_MODULE_LOCATION[5]="/updates/dkms/" >> DEST_MODULE_LOCATION[6]="/updates/dkms/" >> -DEST_MODULE_LOCATION[6]="/updates/dkms/" >> +DEST_MODULE_LOCATION[7]="/updates/dkms/" >> >> AUTOINSTALL="yes" >> >> 2. I can see F1814 sound card under /proc/asound however KDE reports >> after some time that the device has been remover. Here is the kernel >> messages >> >> Jan 5 17:05:57 kirogaz kernel: [ 2244.554306] firewire_core >> 0000:09:00.0: created device fw1: GUID 000d6c0410ebdb45, S400 >> Jan 5 17:05:57 kirogaz kernel: [ 2244.554310] firewire_core >> 0000:09:00.0: phy config: new root=ffc0, gap_count=5 >> Jan 5 17:06:00 kirogaz kernel: [ 2247.658545] firewire_core >> 0000:09:00.0: phy config: new root=ffc1, gap_count=5 >> Jan 5 17:06:11 kirogaz kernel: [ 2258.175114] snd-bebob fw1.0: failed >> to initialize clock params >> Jan 5 17:06:11 kirogaz kernel: [ 2258.188055] firewire_core >> 0000:09:00.0: refreshed device fw1 >> Jan 5 17:06:20 kirogaz kernel: [ 2267.912554] snd-bebob fw1.0: >> isochronous resource deallocation failed >> Jan 5 17:06:27 kirogaz kernel: [ 2275.085005] snd-bebob fw1.0: >> transaction failed: no ack >> Jan 5 17:07:32 kirogaz kernel: [ 2339.395214] firewire_core >> 0000:09:00.0: phy config: new root=ffc1, gap_count=5 >> Jan 5 17:07:32 kirogaz kernel: [ 2339.853183] firewire_core >> 0000:09:00.0: created device fw1: GUID 000d6c0410ebdb45, S400 >> Jan 5 17:07:35 kirogaz kernel: [ 2343.009477] firewire_core >> 0000:09:00.0: phy config: new root=ffc1, gap_count=5 >> Jan 5 17:07:41 kirogaz kernel: [ 2348.520553] snd-bebob fw1.0: failed >> to initialize clock params >> Jan 5 17:07:43 kirogaz kernel: [ 2350.556563] firewire_core >> 0000:09:00.0: refreshed device fw1 >> Jan 5 17:08:33 kirogaz kernel: [ 2400.145899] snd-bebob fw1.0: iPCR0: >> plug is already in use >> Jan 5 17:08:33 kirogaz kernel: [ 2400.370598] snd-bebob fw1.0: iPCR0: >> plug is already in use >> Jan 5 17:08:44 kirogaz kernel: [ 2411.844333] snd-bebob fw1.0: iPCR0: >> plug is already in use >> Jan 5 17:08:47 kirogaz kernel: [ 2414.193002] snd-bebob fw1.0: iPCR0: >> plug is already in use >> Jan 5 17:08:47 kirogaz kernel: [ 2414.815634] snd-bebob fw1.0: iPCR0: >> plug is already in use >> Jan 5 17:08:50 kirogaz kernel: [ 2417.249864] snd-bebob fw1.0: iPCR0: >> plug is already in use >> Jan 5 17:08:50 kirogaz kernel: [ 2417.875256] snd-bebob fw1.0: iPCR0: >> plug is already in use >> Jan 5 17:08:51 kirogaz kernel: [ 2418.178726] snd-bebob fw1.0: iPCR0: >> plug is already in use >> >> I do not have FFADO or JACK installed except my working copy in a >> sandbox so they do not started automatically >> >> Modules are loaded >> >> snd_bebob 40872 0 >> snd_firewire_lib 29430 1 snd_bebob >> >> Here is the contents of some useful files. The strange here is clock freq >> >> Sampling rate: 176400 >> Clock Source: Internal with Digital Mute >> >> cat cards >> 0 [PCH ]: HDA-Intel - HDA Intel PCH >> HDA Intel PCH at 0xfbf20000 irq 84 >> 1 [F1814 ]: BeBoB - FW 1814 >> M-AUDIO FW 1814 (id:131, rev:1), GUID >> 000d6c0400ebdb45 at fw1.0, S400 >> 2 [HDMI ]: HDA-Intel - HDA ATI HDMI >> HDA ATI HDMI at 0xfbe60000 irq 85 >> 3 [Adapter ]: USB-Audio - Rocksmith USB Guitar Adapter >> Hercules Rocksmith USB Guitar Adapter at >> usb-0000:00:1d.0-1.5, full speed >> >> >> find . -type f -exec cat {} \; >> F1814 >> Manufacturer: bridgeCo >> Protocol Ver: 1 >> Build Ver: 0 >> GUID: 0x000D6C0400EBDB45 >> Model ID: 0x83 >> Model Rev: 1 >> Firmware Date: 20070713 >> Firmware Time: 080440 >> Firmware ID: 0x0 >> Firmware Ver: 0 >> Base Addr: 0x20080000 >> Max Size: 1572864 >> Loader Date: 20040330 >> Loader Time: 025909 >> Output Stream from device: >> Rate PCM MIDI >> 22050 0 0 >> 24000 0 0 >> 32000 0 0 >> 44100 10 1 >> 48000 10 1 >> 88200 10 1 >> 96000 10 1 >> 176400 2 1 >> 192000 2 1 >> Input Stream to device: >> Rate PCM MIDI >> 22050 0 0 >> 24000 0 0 >> 32000 0 0 >> 44100 6 1 >> 48000 6 1 >> 88200 6 1 >> 96000 6 1 >> 176400 4 1 >> 192000 4 1 >> Sampling rate: 176400 >> Clock Source: Internal with Digital Mute >> Analog In 1: 0 >> Analog In 2: 0 >> Analog In 3: 0 >> Analog In 4: 0 >> Analog In 5: 0 >> Analog In 6: 0 >> Analog In 7: 0 >> Analog In 8: 0 >> S/PDIF In 1: 0 >> S/PDIF In 2: 0 >> ADAT In 1: 0 >> ADAT In 2: 0 >> ADAT In 3: 0 >> ADAT In 4: 0 >> ADAT In 5: 0 >> ADAT In 6: 0 >> ADAT In 7: 0 >> ADAT In 8: 0 >> Analog Out 1: 0 >> Analog Out 2: 0 >> Analog Out 3: 0 >> Analog Out 4: 0 >> S/PDIF Out 1: 0 >> S/PDIF Out 2: 0 >> ADAT Out 1: 0 >> ADAT Out 2: 0 >> ADAT Out 3: 0 >> ADAT Out 4: 0 >> ADAT Out 5: 0 >> ADAT Out 6: 0 >> ADAT Out 7: 0 >> ADAT Out 8: 0 >> HP Out 1: 0 >> HP Out 2: 0 >> HP Out 3: 0 >> HP Out 4: 0 >> Aux Out 1: 0 >> Aux Out 2: 0 >> FW 1814 MIDI >> >> Output 0 >> Tx bytes : 0 >> Input 0 >> Rx bytes : 0 >> closed >> closed >> closed >> card: 1 >> device: 0 >> subdevice: 0 >> stream: CAPTURE >> id: BeBoB >> name: FW 1814 PCM >> subname: subdevice #0 >> class: 0 >> subclass: 0 >> subdevices_count: 1 >> subdevices_avail: 1 >> 0 >> card: 1 >> device: 0 >> subdevice: 0 >> stream: CAPTURE >> id: BeBoB >> name: FW 1814 PCM >> subname: subdevice #0 >> class: 0 >> subclass: 0 >> subdevices_count: 1 >> subdevices_avail: 1 >> closed >> closed >> closed >> card: 1 >> device: 0 >> subdevice: 0 >> stream: PLAYBACK >> id: BeBoB >> name: FW 1814 PCM >> subname: subdevice #0 >> class: 0 >> subclass: 0 >> subdevices_count: 1 >> subdevices_avail: 1 >> 0 >> card: 1 >> device: 0 >> subdevice: 0 >> stream: PLAYBACK >> id: BeBoB >> name: FW 1814 PCM >> subname: subdevice #0 >> class: 0 >> subclass: 0 >> subdevices_count: 1 >> subdevices_avail: 1 >> >> >> BR, >> Michael >> >> >> >> >> >> >> >>> Hi all, >>> >>> This is a call for testing my ALSA driver for Fireworks/BeBoB based devices. >>> >>> Please test 'snd-fireworks' for Fireworks and 'snd-bebob' for BeBoB if >>> you have some devices listed in the end of this mail. >>> >>> Status: >>> - still under development >>> - Without snd-dice and Clemens' development (I must do this later) >>> >>> Functionality: >>> - playback/capturing (full duplex) with PCM/MIDI interface >>> - hardware metering for some devices with CONTROL interface >>> - switching clock source/digital interface/digital mode with CONTROL >>> interface >>> - print hardware status with PROC interface >>> >>> Note: >>> - Don't use simultaneously 'ALSA PCM/MIDI playback/capture' and 'jackd >>> with Firewire (FFADO) backend'. Both of them try connecting to the >>> device when another is running. >>> - I add much modification into snd-firewire-lib for full duplex >>> synchronization of receive/transmit AMDTP stream. >>> >>> Requirement: >>> - Linux kernel 3.11 or later because of Juju (nickname of Firewire >>> stack) changing its API. >>> - Dynamic Kernel Module Support (DKMS) is reccomended for safely >>> installing/uninstalling >>> (I work with Ubuntu 13.10) >>> >>> Bug report: >>> - report with /proc/asound/cardX/#XXX >>> - please send your experiences to me with the output >>> >>> How to install (DKMS): >>> 1. $ git clone https://github.com/takaswie/snd-firewire-improve.git >>> 2. $ ln -s $(pwd)/snd-firewire-improve/ /usr/src/alsa-firewire-3.11 >>> (superuser) >>> 3. $ dkms install snd-firewire/3.11 (superuser) >>> >>> How to uninstall (DKMS): >>> 1. $ modprobe -r snd-bebob snd-fireworks snd-firewire-lib (superuser) >>> 2. $ dkms remove ans-firewire/3.11 --all (superuser) >>> 3. $ rm /usr/src/alsa-firewire-3.11 (superuser) >>> 4. $ rm snd-firewire-improve >>> >>> How to install (Manual): >>> 1. $ git clone https://github.com/takaswie/snd-firewire-improve.git >>> 2. $ cd snd-firewire-improve >>> 3. $ make >>> 4, backup system snd-firewire-lib/snd-firewire-speakers/snd-isight >>> (superuser) >>> 5. install >>> snd-firewire-lib/snd-firewire-speakers/snd-isight/snd-fireworks/snd-bebob (superuser) >>> 6. depmod -a (superuser) >>> >>> How to uninstall (Manual) >>> 1. modprobe -r snd-firewire-lib snd-firewire-speakers snd-isight >>> snd-fireworks snd-bebob (superuser) >>> 2. remove >>> snd-firewire-lib/snd-firewire-speakers/snd-isight/snd-fireworks/snd-bebob (superuser) >>> 3. recover snd-firewire-lib/snd-firewire-speakers/snd-isight (superuser) >>> 4. depmod -a (superuser) >>> >>> Confirmed to work: >>> - AudioFire4 >>> - AudioFirePre8 >>> - Ozonic >>> - Firewire Solo >>> - Firewire Audiophile >>> - Firewire 410 >>> >>> == Fireworks based devices >>> [Echo Audio] >>> AudioFire2 >>> AudioFire4 >>> AudioFirePre8 >>> AudioFire8 (till 2009) >>> AudioFire8 (since 2009) >>> AudioFire12 >>> >>> [Gibson] >>> RIP >>> >>> [Mackie] >>> Onyx 400F >>> Onyx 1200F >>> >>> == BeBoB based devices >>> [Yamaha] >>> GO44 >>> GO46 >>> >>> [M-Audio] >>> (to control mixer channels please use FFADO upstream) >>> Ozonic >>> Firewire 410 >>> Firewire Audiophile >>> Firewire Solo >>> NRV10 >>> ProFireLightbridge >>> >>> [Focusrite] >>> SaffirePro 26 I/O >>> SaffirePro 10 I/O >>> Saffire(LE) >>> >>> [Edirol] >>> FA-66 >>> FA-101 >>> >>> [TerraTecElectronic GmbH] >>> Phase88FW >>> PhaseX24FW >>> >>> [PreSonus] >>> FireBox >>> FirePod >>> >>> [Mackie] >>> OnyxFirewire >>> >>> [Tascam] >>> IF-FW/DM >>> >>> [Behringer] >>> X32 >>> >>> [ApogeeElectronics] >>> Rosetta200 >>> >>> [ESI] >>> Quatafire610 >>> >>> >>> Regards >>> >>> Takashi Sakamoto >>> o-t...@sa... >>> >>> ------------------------------------------------------------------------------ >>> October Webinars: Code for Performance >>> Free Intel webinars can help you accelerate application performance. >>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from >>> the latest Intel processors and coprocessors. See abstracts and register > >>> http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk >>> _______________________________________________ >>> FFADO-devel mailing list >>> FFA...@li... >>> https://lists.sourceforge.net/lists/listinfo/ffado-devel >> ------------------------------------------------------------------------------ >> Rapidly troubleshoot problems before they affect your business. Most IT >> organizations don't have a clear picture of how application performance >> affects their revenue. With AppDynamics, you get 100% visibility into your >> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! >> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk >> _______________________________________________ >> FFADO-devel mailing list >> FFA...@li... >> https://lists.sourceforge.net/lists/listinfo/ffado-devel > > ------------------------------------------------------------------------------ > Rapidly troubleshoot problems before they affect your business. Most IT > organizations don't have a clear picture of how application performance > affects their revenue. With AppDynamics, you get 100% visibility into your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk > _______________________________________________ > FFADO-devel mailing list > FFA...@li... > https://lists.sourceforge.net/lists/listinfo/ffado-devel |
From: Michael M. <mih...@ya...> - 2014-01-05 23:54:25
|
(resending, it seams the previous attempt failed ) I have looked at the code of snd_bebob_maudio_special_discover(struct snd_bebob *bebob, bool is1814) { int err; bebob->maudio_is1814 = is1814; /* initialize these parameters because driver is not allowed to ask */ err = special_clk_set_params(bebob, 0x03, 0x00, 0x00, 0x00); if (err < 0) dev_err(&bebob->unit->device, "failed to initialize clock params\n"); err = avc_audio_get_selector(bebob->unit, 0x00, 0x04, &bebob->dig_in_iface); if (err < 0) dev_err(&bebob->unit->device, "failed to get current dig iface."); err = snd_bebob_maudio_special_add_controls(bebob); if (err < 0) return -EIO; special_stream_formation_set(bebob); if (bebob->maudio_is1814) { bebob->midi_input_ports = 1; bebob->midi_output_ports = 1; } else { bebob->midi_input_ports = 2; bebob->midi_output_ports = 2; } bebob->maudio_special_quirk = true; return 0; } it seams to me there is a bug here. If special_clk_set_params fails but later snd_bebob_maudio_special_add_controls doesn't fail snd_bebob_maudio_special_discover will return 0. The same for avc_audio_get_selector. Was it done by intension? Or just missed 'return -EIO'. It explains why I see ALSA card but the device doesn't really functioning. I also found another bug in bebob_probe near line 212 bebob->card_index = -1; bebob->spec = spec; context must be initialized or amdtp_stream_running() will fail before amdtp_stream_init() is called + bebob->rx_stream.context = ERR_PTR(-1); + bebob->tx_stream.context = ERR_PTR(-1); mutex_init(&bebob->mutex); spin_lock_init(&bebob->lock); init_waitqueue_head(&bebob->hwdep_wait); Now I can play pink noise using speaker-test -F S32_LE -D sysdefault:CARD=F1814 -r 44100 command. Actually I cannot hear it because it is played through SPDIF output so I only can see green led (i do not have SPDIF devices to try). I can also see in #meter file that values on SPDIF are chganging. My main question now is how to play sound through analogue output ? --Michael |
From: Takashi S. <o-t...@sa...> - 2014-01-06 15:21:20
Attachments:
special_mixer.patch
|
(Jan 6 2014 23:52), Takashi Sakamoto wrote: > Would you please test an attached patch. This patch still has some > issues but you can control internal mixer. Oops. I'm sorry but the attached patch in previous e-mail is not full. Please refer to this attached patch. Regards Takashi Sakamoto |
From: Michael M. <mih...@ya...> - 2014-01-07 10:08:39
|
Hi Takashi, FFADO failed to discover FW 1814 FFADO test and diagnostic utility Part of the FFADO project -- www.ffado.org Version: 2.1.9999-2470M (C) 2008, Daniel Wagner, Pieter Palmers This program comes with ABSOLUTELY NO WARRANTY. ----------------------------------------------- 00641717323: Debug (devicemanager.cpp)[ 354] discover: Starting discovery... 00641789412: Debug (devicemanager.cpp)[ 616] discover: driver found for device 1 00641789441: Debug (bebob_avdevice.cpp)[ 844] loadFromCache: filename /home/ruinmmal/.ffado/cache/000d6c0400ebdb45/0000000003020201.xml 00641789450: Debug (bebob_avdevice.cpp)[ 848] loadFromCache: "/home/ruinmmal/.ffado/cache/000d6c0400ebdb45/0000000003020201.xml" does not exist 00641789455: Debug (avc_unit.cpp)[ 366] discoverPlugs: Discovering plugs... 00641804142: Debug (avc_unit.cpp)[ 383] discoverPlugs: number of iso input plugs = 3 00641804171: Debug (avc_unit.cpp)[ 385] discoverPlugs: number of iso output plugs = 2 00641804175: Debug (avc_unit.cpp)[ 387] discoverPlugs: number of external input plugs = 4 00641804179: Debug (avc_unit.cpp)[ 389] discoverPlugs: number of external output plugs = 7 00641804181: Debug (avc_unit.cpp)[ 426] discoverPlugsPCR: Discovering PCR plugs, direction 0... 00641812227: Error (bebob_avplug.cpp)[ 237] discoverPlugType: Plug does not implement extended plug info plug type info command 00641812235: Error (bebob_avplug.cpp)[ 120] discover: discover: Could not discover plug type (1,31,255,0,0) 00641812240: Error (avc_unit.cpp)[ 442] discoverPlugsPCR: plug discovering failed 00641812265: Error (avc_unit.cpp)[ 394] discoverPlugs: pcr input plug discovering failed 00641812272: Warning (maudio_special_avdevice.cpp)[ 80] discover: Could not find some plugs 00641812273: Error (devicemanager.cpp)[ 628] discover: could not discover device 00641812372: Debug (devicemanager.cpp)[ 661] discover: Discovery finished... 00641812378: Debug (devicemanager.cpp)[1258] showDeviceInfo: ===== Device Manager ===== 00641812382: Debug (Element.cpp)[ 121] show: Element DeviceManager 00641812383: Debug (devicemanager.cpp)[1266] showDeviceInfo: --- IEEE1394 Service 0 --- Iso handler info: Dumping IsoHandlerManager Stream handler information... State: 2 no message buffer overruns BR, Michael On 06.01.2014 19:21, Takashi Sakamoto wrote: > (Jan 6 2014 23:52), Takashi Sakamoto wrote: >> Would you please test an attached patch. This patch still has some >> issues but you can control internal mixer. > > Oops. I'm sorry but the attached patch in previous e-mail is not full. > > Please refer to this attached patch. > > > Regards > > Takashi Sakamoto > |
From: Takashi S. <o-t...@sa...> - 2014-01-07 12:16:46
Attachments:
special_mixer.patch
|
Mi Micheal, > FFADO failed to discover FW 1814 Yes. Please try again after removing these lines: src/bebob/maudio/maudio_special_avdevice.cpp bool SpecialDevice::discover() { - /* discovering 'Serial bus isochronous External plugs' */ - if (!discoverPlugs()) { - debugWarning("Could not find some plugs\n"); - return false; - } - /* keep track of the config id of this discovery */ m_last_discovery_config_id = getConfigurationId(); return true; } Thanks Takashi Sakamoto |
From: Takashi S. <o-t...@sa...> - 2014-01-07 14:18:09
|
Hi Michael, I test my previous patch and have no problems. > I guess this may be a problem with my setup Please retry after moving FFADO cache files under your home directory. $ move ~/.ffado/* ~/somewhere Regards Takashi Sakamoto (2014年01月07日 21:26), Michael Malyshev wrote: > Hi Takashi, > > FFADO can discover FW1814 now and I can see mixer. However I'm getting a > lot of errors like following > > 16:22:08 dbus ERROR Failed to set Continuous > /org/ffado/Control/DeviceManager/000d6c0400ebdb45/Mixer/Feature_Volume_1 > on server org.ffado.Control > 16:22:08 dbus ERROR Failed to set Continuous > /org/ffado/Control/DeviceManager/000d6c0400ebdb45/Mixer/Feature_Volume_1 > on server org.ffado.Control > 16:22:10 dbus ERROR Failed to set Continuous > /org/ffado/Control/DeviceManager/000d6c0400ebdb45/Mixer/Feature_Volume_1 > on server org.ffado.Control > 16:22:10 dbus ERROR Failed to set Continuous > /org/ffado/Control/DeviceManager/000d6c0400ebdb45/Mixer/Feature_Volume_1 > on server org.ffado.Control > > > BR, > Michael > > > On 07.01.2014 16:16, Takashi Sakamoto wrote: >> Mi Micheal, >> >> > FFADO failed to discover FW 1814 >> >> Yes. Please try again after removing these lines: >> >> src/bebob/maudio/maudio_special_avdevice.cpp >> bool SpecialDevice::discover() >> { >> - /* discovering 'Serial bus isochronous External plugs' */ >> - if (!discoverPlugs()) { >> - debugWarning("Could not find some plugs\n"); >> - return false; >> - } >> - >> /* keep track of the config id of this discovery */ >> m_last_discovery_config_id = getConfigurationId(); >> >> return true; >> } >> >> Thanks >> >> >> Takashi Sakamoto >> > > |
From: Michael M. <mih...@ya...> - 2014-01-07 14:55:39
|
unfortunately the same result. Probably dbus server is not started correctly... --Michael > Hi Michael, > > I test my previous patch and have no problems. > > > I guess this may be a problem with my setup > > Please retry after moving FFADO cache files under your home directory. > > $ move ~/.ffado/* ~/somewhere > > > Regards > > Takashi Sakamoto > > (2014年01月07日 21:26), Michael Malyshev wrote: >> Hi Takashi, >> >> FFADO can discover FW1814 now and I can see mixer. However I'm getting a >> lot of errors like following >> >> 16:22:08 dbus ERROR Failed to set Continuous >> /org/ffado/Control/DeviceManager/000d6c0400ebdb45/Mixer/Feature_Volume_1 >> on server org.ffado.Control >> 16:22:08 dbus ERROR Failed to set Continuous >> /org/ffado/Control/DeviceManager/000d6c0400ebdb45/Mixer/Feature_Volume_1 >> on server org.ffado.Control >> 16:22:10 dbus ERROR Failed to set Continuous >> /org/ffado/Control/DeviceManager/000d6c0400ebdb45/Mixer/Feature_Volume_1 >> on server org.ffado.Control >> 16:22:10 dbus ERROR Failed to set Continuous >> /org/ffado/Control/DeviceManager/000d6c0400ebdb45/Mixer/Feature_Volume_1 >> on server org.ffado.Control >> >> >> BR, >> Michael >> >> >> On 07.01.2014 16:16, Takashi Sakamoto wrote: >>> Mi Micheal, >>> >>> > FFADO failed to discover FW 1814 >>> >>> Yes. Please try again after removing these lines: >>> >>> src/bebob/maudio/maudio_special_avdevice.cpp >>> bool SpecialDevice::discover() >>> { >>> - /* discovering 'Serial bus isochronous External plugs' */ >>> - if (!discoverPlugs()) { >>> - debugWarning("Could not find some plugs\n"); >>> - return false; >>> - } >>> - >>> /* keep track of the config id of this discovery */ >>> m_last_discovery_config_id = getConfigurationId(); >>> >>> return true; >>> } >>> >>> Thanks >>> >>> >>> Takashi Sakamoto >>> >> >> > |
From: Takashi S. <o-t...@sa...> - 2014-01-07 15:17:43
|
> unfortunately the same result. Probably dbus server is not started > correctly... Mmm... I'm sorry but currently I have no idea to solve this issue. Takashi Sakamoto |
From: Michael M. <mih...@ya...> - 2014-01-07 16:21:26
|
Hi Jonathan, >>I would need to know more about these "strict requremnts for timings" associated with the FW 1814 before I can comment. I have updated http://subversion.ffado.org/wiki/MaudioBebob/Firewire1814 with my investigation results. Currently no FW transaction should happen at least for 1 second afte sampling frequency is changed. I've found it out from Windows driver and checked manually with firewire-request I understand that this can be handled from user space as well but beening programmer for embedded systems I usually prefer to restrict user space from any dangerous behaviour. May be this is just my habit :) Regards, Michael |
From: Jonathan W. <jw...@ju...> - 2014-01-10 15:08:27
|
Hi Michael On Tue, Jan 07, 2014 at 08:21:15PM +0400, Michael Malyshev wrote: > > I would need to know more about these "strict requremnts for > > timings" associated with the FW 1814 before I can comment. > > I have updated > http://subversion.ffado.org/wiki/MaudioBebob/Firewire1814 with my > investigation results. Currently no FW transaction should happen at > least for 1 second afte sampling frequency is changed. > I've found it out from Windows driver and checked manually with > firewire-request Thanks for this. I will take a closer look at this once I have returned from linux.conf.au. > I understand that this can be handled from user space as well but > beening programmer for embedded systems I usually prefer to restrict > user space from any dangerous behaviour. May be this is just my > habit :) Fair enough. :-) jonathan |
From: Michael M. <mih...@ya...> - 2014-01-07 12:26:57
|
Hi Takashi, FFADO can discover FW1814 now and I can see mixer. However I'm getting a lot of errors like following 16:22:08 dbus ERROR Failed to set Continuous /org/ffado/Control/DeviceManager/000d6c0400ebdb45/Mixer/Feature_Volume_1 on server org.ffado.Control 16:22:08 dbus ERROR Failed to set Continuous /org/ffado/Control/DeviceManager/000d6c0400ebdb45/Mixer/Feature_Volume_1 on server org.ffado.Control 16:22:10 dbus ERROR Failed to set Continuous /org/ffado/Control/DeviceManager/000d6c0400ebdb45/Mixer/Feature_Volume_1 on server org.ffado.Control 16:22:10 dbus ERROR Failed to set Continuous /org/ffado/Control/DeviceManager/000d6c0400ebdb45/Mixer/Feature_Volume_1 on server org.ffado.Control I guess this may be a problem with my setup BR, Michael On 07.01.2014 16:16, Takashi Sakamoto wrote: > Mi Micheal, > > > FFADO failed to discover FW 1814 > > Yes. Please try again after removing these lines: > > src/bebob/maudio/maudio_special_avdevice.cpp > bool SpecialDevice::discover() > { > - /* discovering 'Serial bus isochronous External plugs' */ > - if (!discoverPlugs()) { > - debugWarning("Could not find some plugs\n"); > - return false; > - } > - > /* keep track of the config id of this discovery */ > m_last_discovery_config_id = getConfigurationId(); > > return true; > } > > Thanks > > > Takashi Sakamoto > |
From: Jonathan W. <jw...@ju...> - 2014-01-07 15:39:29
|
On Tue, Jan 07, 2014 at 04:26:48PM +0400, Michael Malyshev wrote: > FFADO can discover FW1814 now and I can see mixer. However I'm getting a > lot of errors like following > > 16:22:08 dbus ERROR Failed to set Continuous > /org/ffado/Control/DeviceManager/000d6c0400ebdb45/Mixer/Feature_Volume_1 > on server org.ffado.Control > 16:22:08 dbus ERROR Failed to set Continuous > /org/ffado/Control/DeviceManager/000d6c0400ebdb45/Mixer/Feature_Volume_1 > on server org.ffado.Control > 16:22:10 dbus ERROR Failed to set Continuous > /org/ffado/Control/DeviceManager/000d6c0400ebdb45/Mixer/Feature_Volume_1 > on server org.ffado.Control > 16:22:10 dbus ERROR Failed to set Continuous > /org/ffado/Control/DeviceManager/000d6c0400ebdb45/Mixer/Feature_Volume_1 > on server org.ffado.Control > > I guess this may be a problem with my setup Probably. It appears that ffado-dbus-server has not been started automatically either by your system or ffado-mixer. What happens when you try to start it manually: ffado-dbus-server In most cases, an installed FFADO will have ffado-dbus-server started when the device is detected by the kernel. Failing that, ffado-mixer will start it. The messages above do tend to indicate that ffado-dbus-server is not running. Regards jonathan |
From: Takashi S. <o-t...@sa...> - 2014-01-06 04:39:46
|
Hi Michael, Thanks for your testing. > 1. snd-bebob is not build. It seams dkms.conf contains error. Here is > my patch to workaround the problem. It's my fault to commit snd-oxfw. I did just copy and paste these lines... I committed your patch to fix them. https://github.com/takaswie/snd-firewire-improve/commit/2328d1f106ea11bbf3d9316d7d8d1398595a269a > [ 2400.145899] snd-bebob fw1.0: iPCR0: plug is already in use > [ 2400.370598] snd-bebob fw1.0: iPCR0: plug is already in use > ... This means that the driver failed to release iPCR[0] after establishing connections. I guess you had tried to playback before. For FW1814 (and ProjectMix I/O), this often appears. I noted: http://sourceforge.net/mailarchive/message.php?msg_id=31772259 M-Audio special firmware quirks: - They can't handle frequent transactions. In this reason, this driver often fail to handle them. There is only a way to recover from this state, powering-off and on. Regards Takashi Sakamoto (2014年01月05日 22:28), Michael Malyshev wrote: > Hi Takashi, > > I have tested your driver with FW1814 on Linux kernel 3.11.5 installed > on Linux Mint 15 and have found following issues so far > > 1. snd-bebob is not build. It seams dkms.conf contains error. Here is my > patch to workaround the problem. I'm not familiar with DKMS builds so I > may be wrong > > diff --git a/dkms.conf b/dkms.conf > index 888ec71..06e9123 100644 > --- a/dkms.conf > +++ b/dkms.conf > @@ -12,7 +12,7 @@ BUILT_MODULE_LOCATION[3]="./sound/firewire" > BUILT_MODULE_LOCATION[4]="./sound/firewire" > BUILT_MODULE_LOCATION[5]="./sound/firewire/fireworks" > BUILT_MODULE_LOCATION[6]="./sound/firewire/bebob" > -BUILT_MODULE_LOCATION[6]="./sound/firewire/oxfw" > +BUILT_MODULE_LOCATION[7]="./sound/firewire/oxfw" > > BUILT_MODULE_NAME[0]="snd-firewire-lib" > BUILT_MODULE_NAME[1]="snd-firewire-speakers" > @@ -21,7 +21,7 @@ BUILT_MODULE_NAME[3]="snd-scs1x" > BUILT_MODULE_NAME[4]="snd-dice" > BUILT_MODULE_NAME[5]="snd-fireworks" > BUILT_MODULE_NAME[6]="snd-bebob" > -BUILT_MODULE_NAME[6]="snd-oxfw" > +BUILT_MODULE_NAME[7]="snd-oxfw" > > DEST_MODULE_LOCATION[0]="/updates/dkms/" > DEST_MODULE_LOCATION[1]="/updates/dkms/" > @@ -30,6 +30,6 @@ DEST_MODULE_LOCATION[3]="/updates/dkms/" > DEST_MODULE_LOCATION[4]="/updates/dkms/" > DEST_MODULE_LOCATION[5]="/updates/dkms/" > DEST_MODULE_LOCATION[6]="/updates/dkms/" > -DEST_MODULE_LOCATION[6]="/updates/dkms/" > +DEST_MODULE_LOCATION[7]="/updates/dkms/" > > AUTOINSTALL="yes" > > 2. I can see F1814 sound card under /proc/asound however KDE reports > after some time that the device has been remover. Here is the kernel > messages > > Jan 5 17:05:57 kirogaz kernel: [ 2244.554306] firewire_core > 0000:09:00.0: created device fw1: GUID 000d6c0410ebdb45, S400 > Jan 5 17:05:57 kirogaz kernel: [ 2244.554310] firewire_core > 0000:09:00.0: phy config: new root=ffc0, gap_count=5 > Jan 5 17:06:00 kirogaz kernel: [ 2247.658545] firewire_core > 0000:09:00.0: phy config: new root=ffc1, gap_count=5 > Jan 5 17:06:11 kirogaz kernel: [ 2258.175114] snd-bebob fw1.0: failed > to initialize clock params > Jan 5 17:06:11 kirogaz kernel: [ 2258.188055] firewire_core > 0000:09:00.0: refreshed device fw1 > Jan 5 17:06:20 kirogaz kernel: [ 2267.912554] snd-bebob fw1.0: > isochronous resource deallocation failed > Jan 5 17:06:27 kirogaz kernel: [ 2275.085005] snd-bebob fw1.0: > transaction failed: no ack > Jan 5 17:07:32 kirogaz kernel: [ 2339.395214] firewire_core > 0000:09:00.0: phy config: new root=ffc1, gap_count=5 > Jan 5 17:07:32 kirogaz kernel: [ 2339.853183] firewire_core > 0000:09:00.0: created device fw1: GUID 000d6c0410ebdb45, S400 > Jan 5 17:07:35 kirogaz kernel: [ 2343.009477] firewire_core > 0000:09:00.0: phy config: new root=ffc1, gap_count=5 > Jan 5 17:07:41 kirogaz kernel: [ 2348.520553] snd-bebob fw1.0: failed > to initialize clock params > Jan 5 17:07:43 kirogaz kernel: [ 2350.556563] firewire_core > 0000:09:00.0: refreshed device fw1 > Jan 5 17:08:33 kirogaz kernel: [ 2400.145899] snd-bebob fw1.0: iPCR0: > plug is already in use > Jan 5 17:08:33 kirogaz kernel: [ 2400.370598] snd-bebob fw1.0: iPCR0: > plug is already in use > Jan 5 17:08:44 kirogaz kernel: [ 2411.844333] snd-bebob fw1.0: iPCR0: > plug is already in use > Jan 5 17:08:47 kirogaz kernel: [ 2414.193002] snd-bebob fw1.0: iPCR0: > plug is already in use > Jan 5 17:08:47 kirogaz kernel: [ 2414.815634] snd-bebob fw1.0: iPCR0: > plug is already in use > Jan 5 17:08:50 kirogaz kernel: [ 2417.249864] snd-bebob fw1.0: iPCR0: > plug is already in use > Jan 5 17:08:50 kirogaz kernel: [ 2417.875256] snd-bebob fw1.0: iPCR0: > plug is already in use > Jan 5 17:08:51 kirogaz kernel: [ 2418.178726] snd-bebob fw1.0: iPCR0: > plug is already in use > > I do not have FFADO or JACK installed except my working copy in a > sandbox so they do not started automatically > > Modules are loaded > > snd_bebob 40872 0 > snd_firewire_lib 29430 1 snd_bebob > > Here is the contents of some useful files. The strange here is clock freq > > Sampling rate: 176400 > Clock Source: Internal with Digital Mute > > cat cards > 0 [PCH ]: HDA-Intel - HDA Intel PCH > HDA Intel PCH at 0xfbf20000 irq 84 > 1 [F1814 ]: BeBoB - FW 1814 > M-AUDIO FW 1814 (id:131, rev:1), GUID > 000d6c0400ebdb45 at fw1.0, S400 > 2 [HDMI ]: HDA-Intel - HDA ATI HDMI > HDA ATI HDMI at 0xfbe60000 irq 85 > 3 [Adapter ]: USB-Audio - Rocksmith USB Guitar Adapter > Hercules Rocksmith USB Guitar Adapter at > usb-0000:00:1d.0-1.5, full speed > > > find . -type f -exec cat {} \; > F1814 > Manufacturer: bridgeCo > Protocol Ver: 1 > Build Ver: 0 > GUID: 0x000D6C0400EBDB45 > Model ID: 0x83 > Model Rev: 1 > Firmware Date: 20070713 > Firmware Time: 080440 > Firmware ID: 0x0 > Firmware Ver: 0 > Base Addr: 0x20080000 > Max Size: 1572864 > Loader Date: 20040330 > Loader Time: 025909 > Output Stream from device: > Rate PCM MIDI > 22050 0 0 > 24000 0 0 > 32000 0 0 > 44100 10 1 > 48000 10 1 > 88200 10 1 > 96000 10 1 > 176400 2 1 > 192000 2 1 > Input Stream to device: > Rate PCM MIDI > 22050 0 0 > 24000 0 0 > 32000 0 0 > 44100 6 1 > 48000 6 1 > 88200 6 1 > 96000 6 1 > 176400 4 1 > 192000 4 1 > Sampling rate: 176400 > Clock Source: Internal with Digital Mute > Analog In 1: 0 > Analog In 2: 0 > Analog In 3: 0 > Analog In 4: 0 > Analog In 5: 0 > Analog In 6: 0 > Analog In 7: 0 > Analog In 8: 0 > S/PDIF In 1: 0 > S/PDIF In 2: 0 > ADAT In 1: 0 > ADAT In 2: 0 > ADAT In 3: 0 > ADAT In 4: 0 > ADAT In 5: 0 > ADAT In 6: 0 > ADAT In 7: 0 > ADAT In 8: 0 > Analog Out 1: 0 > Analog Out 2: 0 > Analog Out 3: 0 > Analog Out 4: 0 > S/PDIF Out 1: 0 > S/PDIF Out 2: 0 > ADAT Out 1: 0 > ADAT Out 2: 0 > ADAT Out 3: 0 > ADAT Out 4: 0 > ADAT Out 5: 0 > ADAT Out 6: 0 > ADAT Out 7: 0 > ADAT Out 8: 0 > HP Out 1: 0 > HP Out 2: 0 > HP Out 3: 0 > HP Out 4: 0 > Aux Out 1: 0 > Aux Out 2: 0 > FW 1814 MIDI > > Output 0 > Tx bytes : 0 > Input 0 > Rx bytes : 0 > closed > closed > closed > card: 1 > device: 0 > subdevice: 0 > stream: CAPTURE > id: BeBoB > name: FW 1814 PCM > subname: subdevice #0 > class: 0 > subclass: 0 > subdevices_count: 1 > subdevices_avail: 1 > 0 > card: 1 > device: 0 > subdevice: 0 > stream: CAPTURE > id: BeBoB > name: FW 1814 PCM > subname: subdevice #0 > class: 0 > subclass: 0 > subdevices_count: 1 > subdevices_avail: 1 > closed > closed > closed > card: 1 > device: 0 > subdevice: 0 > stream: PLAYBACK > id: BeBoB > name: FW 1814 PCM > subname: subdevice #0 > class: 0 > subclass: 0 > subdevices_count: 1 > subdevices_avail: 1 > 0 > card: 1 > device: 0 > subdevice: 0 > stream: PLAYBACK > id: BeBoB > name: FW 1814 PCM > subname: subdevice #0 > class: 0 > subclass: 0 > subdevices_count: 1 > subdevices_avail: 1 > > > BR, > Michael > > > > > > > >> Hi all, >> >> This is a call for testing my ALSA driver for Fireworks/BeBoB based devices. >> >> Please test 'snd-fireworks' for Fireworks and 'snd-bebob' for BeBoB if >> you have some devices listed in the end of this mail. >> >> Status: >> - still under development >> - Without snd-dice and Clemens' development (I must do this later) >> >> Functionality: >> - playback/capturing (full duplex) with PCM/MIDI interface >> - hardware metering for some devices with CONTROL interface >> - switching clock source/digital interface/digital mode with CONTROL >> interface >> - print hardware status with PROC interface >> >> Note: >> - Don't use simultaneously 'ALSA PCM/MIDI playback/capture' and 'jackd >> with Firewire (FFADO) backend'. Both of them try connecting to the >> device when another is running. >> - I add much modification into snd-firewire-lib for full duplex >> synchronization of receive/transmit AMDTP stream. >> >> Requirement: >> - Linux kernel 3.11 or later because of Juju (nickname of Firewire >> stack) changing its API. >> - Dynamic Kernel Module Support (DKMS) is reccomended for safely >> installing/uninstalling >> (I work with Ubuntu 13.10) >> >> Bug report: >> - report with /proc/asound/cardX/#XXX >> - please send your experiences to me with the output >> >> How to install (DKMS): >> 1. $ git clone https://github.com/takaswie/snd-firewire-improve.git >> 2. $ ln -s $(pwd)/snd-firewire-improve/ /usr/src/alsa-firewire-3.11 >> (superuser) >> 3. $ dkms install snd-firewire/3.11 (superuser) >> >> How to uninstall (DKMS): >> 1. $ modprobe -r snd-bebob snd-fireworks snd-firewire-lib (superuser) >> 2. $ dkms remove ans-firewire/3.11 --all (superuser) >> 3. $ rm /usr/src/alsa-firewire-3.11 (superuser) >> 4. $ rm snd-firewire-improve >> >> How to install (Manual): >> 1. $ git clone https://github.com/takaswie/snd-firewire-improve.git >> 2. $ cd snd-firewire-improve >> 3. $ make >> 4, backup system snd-firewire-lib/snd-firewire-speakers/snd-isight >> (superuser) >> 5. install >> snd-firewire-lib/snd-firewire-speakers/snd-isight/snd-fireworks/snd-bebob (superuser) >> 6. depmod -a (superuser) >> >> How to uninstall (Manual) >> 1. modprobe -r snd-firewire-lib snd-firewire-speakers snd-isight >> snd-fireworks snd-bebob (superuser) >> 2. remove >> snd-firewire-lib/snd-firewire-speakers/snd-isight/snd-fireworks/snd-bebob (superuser) >> 3. recover snd-firewire-lib/snd-firewire-speakers/snd-isight (superuser) >> 4. depmod -a (superuser) >> >> Confirmed to work: >> - AudioFire4 >> - AudioFirePre8 >> - Ozonic >> - Firewire Solo >> - Firewire Audiophile >> - Firewire 410 >> >> == Fireworks based devices >> [Echo Audio] >> AudioFire2 >> AudioFire4 >> AudioFirePre8 >> AudioFire8 (till 2009) >> AudioFire8 (since 2009) >> AudioFire12 >> >> [Gibson] >> RIP >> >> [Mackie] >> Onyx 400F >> Onyx 1200F >> >> == BeBoB based devices >> [Yamaha] >> GO44 >> GO46 >> >> [M-Audio] >> (to control mixer channels please use FFADO upstream) >> Ozonic >> Firewire 410 >> Firewire Audiophile >> Firewire Solo >> NRV10 >> ProFireLightbridge >> >> [Focusrite] >> SaffirePro 26 I/O >> SaffirePro 10 I/O >> Saffire(LE) >> >> [Edirol] >> FA-66 >> FA-101 >> >> [TerraTecElectronic GmbH] >> Phase88FW >> PhaseX24FW >> >> [PreSonus] >> FireBox >> FirePod >> >> [Mackie] >> OnyxFirewire >> >> [Tascam] >> IF-FW/DM >> >> [Behringer] >> X32 >> >> [ApogeeElectronics] >> Rosetta200 >> >> [ESI] >> Quatafire610 >> >> >> Regards >> >> Takashi Sakamoto >> o-t...@sa... >> >> ------------------------------------------------------------------------------ >> October Webinars: Code for Performance >> Free Intel webinars can help you accelerate application performance. >> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from >> the latest Intel processors and coprocessors. See abstracts and register > >> http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk >> _______________________________________________ >> FFADO-devel mailing list >> FFA...@li... >> https://lists.sourceforge.net/lists/listinfo/ffado-devel > > > ------------------------------------------------------------------------------ > Rapidly troubleshoot problems before they affect your business. Most IT > organizations don't have a clear picture of how application performance > affects their revenue. With AppDynamics, you get 100% visibility into your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk > _______________________________________________ > FFADO-devel mailing list > FFA...@li... > https://lists.sourceforge.net/lists/listinfo/ffado-devel > |
From: Michael M. <mih...@ya...> - 2014-01-07 12:14:21
|
Hi Takashi, > It seams to me FW1814 has strict timing diagram. > I'll check with bus analyser one more time how long delays > in Windows driver for FCP transactions. >That's nice. I have checked timing digram for FW 1814 1. Driver polls for meter data every 100 ms 2. Any FCP transaction (except 'lock pll' and 'set sampling rate') happens in less then 100 ms 3. Any regular read/write happens at any time (e.g. mixer controls) 4. The most interesting part: set sampling rate. Here is the part of the log with timings 46 ffc1 ffff f000 0b00 8 OUT 00 ff 18 00 90 03 ff ff ........ 2.8ms 80.1.0 15:06:58.773 mafw 46 0000 ffff f000 0d00 8 IN 0f ff 18 00 90 03 ff ff ........ 106ms 81.1.0 15:06:58.883 mafw 46 0000 ffff f000 0d00 8 IN 09 ff 18 00 90 03 ff ff ........ 132ms 82.1.0 15:06:59.013 mafw this reply usualy arrives after about 150 ms 46 ffc1 ffff f000 0b00 8 OUT 00 ff 19 00 90 03 ff ff ........ 1.4ms 83.1.0 15:06:59.013 mafw 46 0000 ffff f000 0d00 8 IN 0f ff 19 00 90 03 ff ff ........ 91ms 84.1.0 15:06:59.103 mafw 46 0000 ffff f000 0d00 8 IN 09 ff 19 00 90 03 ff ff ........ 332ms 85.1.0 15:06:59.443 mafw as you can see reply to FCP request arrived in 332 ms. and the next access to the device happens only aftet 1 sec!!! 46 ffc1 ffc7 0060 0000 84 IN 00 00 00 00 00 05 00 01 00 1a 00 1b 00 1a 00 1a ................ 1.0sc 86.1.0 15:07:00.493 mafw 00 18 00 18 00 00 00 00 00 00 00 00 00 00 00 00 ................ 86.1.16 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 86.1.32 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 86.1.48 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 86.1.64 00 00 03 01 .... 86.1.80 So I guess we need a special function for FW 1814 to deal with these 2 FCP transactions. I would actually implement the whole driver as event driven state machine. In the loop check the queue of requests and if there is no any then poll meter. And delay any pending request for 1 sec after changing sampling rate. >I have a reason not to do it. >I design snd-bebob not to interrupt FFADO streaming function as much as possible. If snd-bebob keep plugs open, FFADO always failed to start streaming after the user uses ALSA application. But why would I need FFADO installed if my audio card is supported by your driver? The reason may be that FFADO already has mixer implemented and probably more stable now, but how about future? > And I design snd-bebob to handle all devices based on DMxxxx/BeBoB. If > we want to implement something special for FW1814 and ProjectMix I/O, > I think it good to develop two driver modules, like snd-bebob and > snd-maudio (or something). > > But currently I avoid the cost to maintain these two drivers. yes, the separate module may be better. Unfortunately I'll be travelling to customer's site for next 4 months so will not be able to help in development :( > > > Another observation is access to meter data. Currently FW > transaction is issues > > for every access to #meter file. > > Should this data be cached? Windows driver polls for data every 100 ms > > in separate thread (synchronized with streaming?). > > My intent to implement #meter node is for debugging purpose. > So currently I have no idea to use it for application in user-land. > > If you need the information, it's better to implement it in user-land > application. I guess #meter node will be very helpful for the one who will implement mixer GUI for particular card(s). I'm not going to change my FW 1814 to anything else sine it is good enough for my needs and I'd love to implement mixer GUI which will work in conjunction with ALSA driver. Regards, Michael |
From: Takashi S. <o-t...@sa...> - 2014-01-07 14:56:30
|
Hi Michael, Your report should be stored as a document. Please add your test in this page. http://subversion.ffado.org/wiki/MaudioBebob/Firewire1814 > But why would I need FFADO installed if my audio card is supported by > your driver? The reason may be that FFADO already has mixer implemented > and probably more stable now, but how about future? In my text, FFADO is an example of implementation in user-land. I hate to make any restrictions in user-land as a result of adding my kernel-land drivers. Users should do everything as long as they have a will to continue to develop software. > I guess #meter node will be very helpful for the one who will implement > mixer GUI for particular card(s). I disagree with this idea because application in user-land can access to device directly via /dev/fw*. I believe this is more useful way. As a quick glance, the #meter node looks preferable... But just a moment. It's dangerous idea! There is no substance of #meter. Why do you hope to access such a virtual node though there is a way to access your device directly via /dev/fw*. Why don't you use it? What do you really want to access? Thanks Takashi Sakamoto (2014年01月07日 21:14), Michael Malyshev wrote: > Hi Takashi, > > > It seams to me FW1814 has strict timing diagram. > > I'll check with bus analyser one more time how long delays > > in Windows driver for FCP transactions. > > >That's nice. > > I have checked timing digram for FW 1814 > > 1. Driver polls for meter data every 100 ms > 2. Any FCP transaction (except 'lock pll' and 'set sampling rate') > happens in less then 100 ms > 3. Any regular read/write happens at any time (e.g. mixer controls) > 4. The most interesting part: set sampling rate. Here is the part of the > log with timings > > 46 ffc1 ffff f000 0b00 8 OUT 00 ff 18 00 90 03 ff > ff ........ 2.8ms 80.1.0 > 15:06:58.773 mafw > 46 0000 ffff f000 0d00 8 IN 0f ff 18 00 90 03 ff > ff ........ 106ms 81.1.0 > 15:06:58.883 mafw > 46 0000 ffff f000 0d00 8 IN 09 ff 18 00 90 03 ff > ff ........ 132ms 82.1.0 > 15:06:59.013 mafw > > this reply usualy arrives after about 150 ms > > 46 ffc1 ffff f000 0b00 8 OUT 00 ff 19 00 90 03 ff > ff ........ 1.4ms 83.1.0 > 15:06:59.013 mafw > 46 0000 ffff f000 0d00 8 IN 0f ff 19 00 90 03 ff > ff ........ 91ms 84.1.0 > 15:06:59.103 mafw > 46 0000 ffff f000 0d00 8 IN 09 ff 19 00 90 03 ff > ff ........ 332ms 85.1.0 > 15:06:59.443 mafw > > as you can see reply to FCP request arrived in 332 ms. and the next > access to the device happens only aftet 1 sec!!! > > 46 ffc1 ffc7 0060 0000 84 IN 00 00 00 00 00 05 00 01 > 00 1a 00 1b 00 1a 00 1a ................ 1.0sc 86.1.0 15:07:00.493 mafw > 00 18 00 18 00 00 00 00 > 00 00 00 00 00 00 00 00 ................ 86.1.16 > 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 ................ 86.1.32 > 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 ................ 86.1.48 > 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 ................ 86.1.64 > 00 00 03 01 > .... 86.1.80 > > > So I guess we need a special function for FW 1814 to deal with these 2 > FCP transactions. I would actually implement the whole driver as event > driven state machine. > In the loop check the queue of requests and if there is no any then poll > meter. And delay any pending request for 1 sec after changing sampling > rate. > > >I have a reason not to do it. > >I design snd-bebob not to interrupt FFADO streaming function as much > as possible. If snd-bebob keep plugs open, FFADO always failed to start > streaming after the user uses ALSA application. > > But why would I need FFADO installed if my audio card is supported by > your driver? The reason may be that FFADO already has mixer implemented > and probably more stable now, but how about future? > >> And I design snd-bebob to handle all devices based on DMxxxx/BeBoB. If >> we want to implement something special for FW1814 and ProjectMix I/O, >> I think it good to develop two driver modules, like snd-bebob and >> snd-maudio (or something). >> >> But currently I avoid the cost to maintain these two drivers. > yes, the separate module may be better. Unfortunately I'll be travelling > to customer's site for next 4 months so will not be able to help in > development :( > >> >> > Another observation is access to meter data. Currently FW >> transaction is issues >> > for every access to #meter file. >> > Should this data be cached? Windows driver polls for data every 100 ms >> > in separate thread (synchronized with streaming?). >> >> My intent to implement #meter node is for debugging purpose. >> So currently I have no idea to use it for application in user-land. >> >> If you need the information, it's better to implement it in user-land >> application. > I guess #meter node will be very helpful for the one who will implement > mixer GUI for particular card(s). I'm not going to change my FW 1814 to > anything else sine it is good enough for my needs and I'd love to > implement mixer GUI which will work in conjunction with ALSA driver. > > Regards, > Michael |
From: Jonathan W. <jw...@ju...> - 2014-01-07 15:26:00
|
On Tue, Jan 07, 2014 at 04:14:10PM +0400, Michael Malyshev wrote: > But why would I need FFADO installed if my audio card is supported by > your driver? The reason may be that FFADO already has mixer implemented > and probably more stable now, but how about future? Device control (for example, onboard mixers, device settings, routings and the like) will at this stage continue to be controlled via userspace using ffado-mixer or something similar. This is because the firewire devices in general have complex mixer requirements which are better dealt with in userspace. Once the ALSA streaming drivers stabilise there will be no need to use the streaming portion of ffado (that is, "jackd -d firewire"). The control portion (accessed currently with ffado-mixer and ffado-dbus-server), which incidently operates completely independently of the streaming component, will remain. At least this is the plan at present. The details of how this fits in for specific devices is yet to be determined. Regards jonathan |
From: Michael M. <mih...@ya...> - 2014-01-07 15:57:30
|
Hi Jonathan, > On Tue, Jan 07, 2014 at 04:14:10PM +0400, Michael Malyshev wrote: >> But why would I need FFADO installed if my audio card is supported by >> your driver? The reason may be that FFADO already has mixer implemented >> and probably more stable now, but how about future? > Device control (for example, onboard mixers, device settings, routings and > the like) will at this stage continue to be controlled via userspace using > ffado-mixer or something similar. This is because the firewire devices in > general have complex mixer requirements which are better dealt with in > userspace. I understand the intention. However I doubt that accessing device from 2 places *independently* (driver and user space) is a good idea. Device control still can be done in user space because of the complexity but through driver, not directly accessing /dev/fw*. Having one 'access point' we have better control of command flow especially when there are strict requremnts for timings like we have for FW 1814 > > Once the ALSA streaming drivers stabilise there will be no need to use the > streaming portion of ffado (that is, "jackd -d firewire"). The control > portion (accessed currently with ffado-mixer and ffado-dbus-server), which > incidently operates completely independently of the streaming component, It is that streaming control and device control 'may' not be so independent > will remain. At least this is the plan at present. The details of how this > fits in for specific devices is yet to be determined. I understand that FW 1814 may be one of the few exceptions, I'm sorry, I do not have good understanding how other devices work and may be current plan is the best approach. Regards, Michael |
From: Jonathan W. <jw...@ju...> - 2014-01-07 16:06:59
|
Hi Michael On Tue, Jan 07, 2014 at 07:57:19PM +0400, Michael Malyshev wrote: > Hi Jonathan, > >On Tue, Jan 07, 2014 at 04:14:10PM +0400, Michael Malyshev wrote: > >>But why would I need FFADO installed if my audio card is supported by > >>your driver? The reason may be that FFADO already has mixer implemented > >>and probably more stable now, but how about future? > >Device control (for example, onboard mixers, device settings, routings and > >the like) will at this stage continue to be controlled via userspace using > >ffado-mixer or something similar. This is because the firewire devices in > >general have complex mixer requirements which are better dealt with in > >userspace. > I understand the intention. However I doubt that accessing device > from 2 places *independently* (driver and user space) is a good > idea. For most devices (at least those I deal with myself) it really is not a problem. The two components (streaming and control) access different registers of the device and as such are more or less independent in operation. Keep in mind that the "driver" in ALSA is really just the code required to access the audio streams associated with the device. > Device control still can be done in user space because of the > complexity but through driver, not directly accessing /dev/fw*. There may be some cases where this proves necessary to a certain extent: it depends on the details of the device itself. For example, if an ARM is required then transactions must be routed via the kernel driver. However, a further complication is that all these devices have *very* different control and mixer requirements and coming up with a kernel API to cover them all is going to be extremely difficult (if not impossible). This is why keeping control in userspace is currently viewed as better idea. Offering a way to utilise a shared ARM if needed is fine, but going beyond that is going to cause difficulties. > Having one 'access point' we have better control of command flow > especially when there are strict requremnts for timings like we have > for FW 1814 I would need to know more about these "strict requremnts for timings" associated with the FW 1814 before I can comment. Regards jonathan |
From: Takashi S. <o-t...@sa...> - 2014-01-06 05:58:14
|
Hi Michael, > If special_clk_set_params fails but later > snd_bebob_maudio_special_add_controls doesn't fail > snd_bebob_maudio_special_discover will return 0. The same for > avc_audio_get_selector. Was it done by intension? Or just missed > 'return -EIO'. Yes. It should return error. But I confirm that these commands are often failed because the device cannot handle frequent requests. So I suggest to make some trials for these commands (i.e. three times with 100msec wait). > context must be initialized or amdtp_stream_running() will fail before > amdtp_stream_init() is called That's reasonable. But I believe the codes should be pushed into bebob_maudio.c because this is required just for snd_bebob_maudio_special_discover(). diff --git a/sound/firewire/bebob/bebob_maudio.c b/sound/firewire/bebob/bebob_maudio.c because it's just required for maudio special devices. index 96e949f..1155d99 100644 --- a/sound/firewire/bebob/bebob_maudio.c +++ b/sound/firewire/bebob/bebob_maudio.c @@ -279,6 +279,8 @@ snd_bebob_maudio_special_discover(struct snd_bebob *bebob, bool is1814) bebob->maudio_is1814 = is1814; /* initialize these parameters because driver is not allowed to ask */ + bebob->rx_stream.context = ERR_PTR(-1); + bebob->tx_stream.context = ERR_PTR(-1); err = special_clk_set_params(bebob, 0x03, 0x00, 0x00, 0x00); if (err < 0) dev_err(&bebob->unit->device, > My main question now is how to play sound through analogue output ? Please set internal mixer correctly with asynchronous transaction. See: http://subversion.ffado.org/wiki/MaudioBebob/Firewire1814 If you use jujuutils, this command set all of stream inputs into all of internal mixers: $ jujuutils-0.2/src/firewire-request /dev/fw1 write 0xffc700700094 0x0000000f > Takashi, could you please share the test procedure you are using? My procedure: [Basic] 1.arecord 2.arecord, aplay 3.aplay 4.aplay, arecord For S32_LE(S16_LE is only for playback) and at every supported sampling rates. [With sound servers] Sometimes use PulseAudio (module-alsa-sink/module-alsa-source with device=F1814,0 options) and JACK(jackd with ALSA backend with -C/-P/-D options at every available sampling rates) Regards Takashi Sakamoto |
From: Малышев М. <mih...@ya...> - 2014-01-06 12:30:55
|
Hi Takashi, >> If special_clk_set_params fails but later >> snd_bebob_maudio_special_add_controls doesn't fail >> snd_bebob_maudio_special_discover will return 0. The same for >> avc_audio_get_selector. Was it done by intension? Or just missed >> 'return -EIO'. > > Yes. It should return error. > > But I confirm that these commands are often failed because the device > cannot handle frequent requests. So I suggest to make some trials for > these commands (i.e. three times with 100msec wait). It seams to me FW1814 has strict timing diagram. I'll check with bus analyser one more time how long delays in Windows driver for FCP transactions. >> context must be initialized or amdtp_stream_running() will fail before >> amdtp_stream_init() is called > > That's reasonable. But I believe the codes should be pushed into > bebob_maudio.c because this is required just for > snd_bebob_maudio_special_discover(). ok > Please set internal mixer correctly with asynchronous transaction. See: > http://subversion.ffado.org/wiki/MaudioBebob/Firewire1814 > > If you use jujuutils, this command set all of stream inputs into all of > internal mixers: > $ jujuutils-0.2/src/firewire-request /dev/fw1 write 0xffc700700094 > 0x0000000f > Thanks. I actually did it, but did it wrong :( . Now I can confirm that the playback is working fine. The next step is mixer control As a nice-to-have feature I have implemented 'indication test command' for FW1814. It blinks all the leds from probe(). Do you know if this command is unique for FW1814 only? Could you try it on other m-audio devices ? firewire-request /dev/fw1 fcp "00 ff 00 02 00 00 00 00" One thing really worries me: the very long startup time for streaming. From Windows driver I can see that input/output plugs are set only once but in current implementation of Linux driver it happens many times and this is time consuming operation. What if we do not release plugs if they have been initialized already and release then only when the driver is unloaded/suspended? Another observation is access to meter data. Currently FW transaction is issues for every access to #meter file. Should this data be cached? Windows driver polls for data every 100 ms in separate thread (synchronized with streaming?). BR, Michael |
From: Darren A. <dar...@gm...> - 2014-01-06 12:49:55
|
>As a nice-to-have feature I have implemented 'indication test command' for FW1814. It blinks all the leds from probe(). Do you know if >this command is unique for FW1814 only? Could you try it on other m-audio devices ? >firewire-request /dev/fw1 fcp "00 ff 00 02 00 00 00 00" I can confirm that this also works for the ProjectMix I/O. I'd assume it's just for these two devices. On Mon, Jan 6, 2014 at 12:30 PM, Малышев Михаил <mih...@ya...>wrote: > Hi Takashi, > > >> If special_clk_set_params fails but later > >> snd_bebob_maudio_special_add_controls doesn't fail > >> snd_bebob_maudio_special_discover will return 0. The same for > >> avc_audio_get_selector. Was it done by intension? Or just missed > >> 'return -EIO'. > > > > Yes. It should return error. > > > > But I confirm that these commands are often failed because the device > > cannot handle frequent requests. So I suggest to make some trials for > > these commands (i.e. three times with 100msec wait). > > It seams to me FW1814 has strict timing diagram. I'll check with bus > analyser one more time how long delays in Windows driver for FCP > transactions. > > >> context must be initialized or amdtp_stream_running() will fail before > >> amdtp_stream_init() is called > > > > That's reasonable. But I believe the codes should be pushed into > > bebob_maudio.c because this is required just for > > snd_bebob_maudio_special_discover(). > > ok > > > Please set internal mixer correctly with asynchronous transaction. See: > > http://subversion.ffado.org/wiki/MaudioBebob/Firewire1814 > > > > If you use jujuutils, this command set all of stream inputs into all of > > internal mixers: > > $ jujuutils-0.2/src/firewire-request /dev/fw1 write 0xffc700700094 > > 0x0000000f > > > > Thanks. I actually did it, but did it wrong :( . Now I can confirm that > the playback is working fine. The next step is mixer control > > As a nice-to-have feature I have implemented 'indication test command' for > FW1814. It blinks all the leds from probe(). Do you know if this command is > unique for FW1814 only? Could you try it on other m-audio devices ? > firewire-request /dev/fw1 fcp "00 ff 00 02 00 00 00 00" > > One thing really worries me: the very long startup time for streaming. > From Windows driver I can see that input/output plugs are set only once but > in current implementation of Linux driver it happens many times and this is > time consuming operation. > What if we do not release plugs if they have been initialized already and > release then only when the driver is unloaded/suspended? > > Another observation is access to meter data. Currently FW transaction is > issues for every access to #meter file. Should this data be cached? Windows > driver polls for data every 100 ms in separate thread (synchronized with > streaming?). > > BR, > Michael > > > > ------------------------------------------------------------------------------ > Rapidly troubleshoot problems before they affect your business. Most IT > organizations don't have a clear picture of how application performance > affects their revenue. With AppDynamics, you get 100% visibility into your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics > Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk > _______________________________________________ > FFADO-devel mailing list > FFA...@li... > https://lists.sourceforge.net/lists/listinfo/ffado-devel > |
From: Takashi S. <o-t...@sa...> - 2014-01-06 14:53:05
Attachments:
special_mixer.patch
|
Hi Michael, (C.C.ed to Darren) > The next step is mixer control Would you please test an attached patch. This patch still has some issues but you can control internal mixer. > It seams to me FW1814 has strict timing diagram. > I'll check with bus analyser one more time how long delays > in Windows driver for FCP transactions. That's nice. > As a nice-to-have feature I have implemented 'indication test command' for FW1814. > It blinks all the leds from probe(). Do you know if this command is unique for FW1814 only? > firewire-request /dev/fw1 fcp "00 ff 00 02 00 00 00 00" This command also blink my FW1814. $ firewire-request /dev/fw1 fcp '00 ff 00 02' I had a wrong understanding for this command: http://subversion.ffado.org/wiki/MaudioBebob/Firewire1814#Resetdevice > Could you try it on other m-audio devices ? It has no effect for my other BeBoB based devices (M-Audio and Yamaha). $ ./firewire-request /dev/fw1 fcp 00ff000200000000 response: 000: 08 ff 00 00 00 00 00 00 > One thing really worries me: the very long startup time for streaming. > From Windows driver I can see that input/output plugs are set only once > but in current implementation of Linux driver it happens many times > and this is time consuming operation. > What if we do not release plugs if they have been initialized already and release then > only when the driver is unloaded/suspended? I have a reason not to do it. I design snd-bebob not to interrupt FFADO streaming function as much as possible. If snd-bebob keep plugs open, FFADO always failed to start streaming after the user uses ALSA application. And I design snd-bebob to handle all devices based on DMxxxx/BeBoB. If we want to implement something special for FW1814 and ProjectMix I/O, I think it good to develop two driver modules, like snd-bebob and snd-maudio (or something). But currently I avoid the cost to maintain these two drivers. > Another observation is access to meter data. Currently FW transaction is issues > for every access to #meter file. > Should this data be cached? Windows driver polls for data every 100 ms > in separate thread (synchronized with streaming?). My intent to implement #meter node is for debugging purpose. So currently I have no idea to use it for application in user-land. If you need the information, it's better to implement it in user-land application. Thanks Takashi Sakamoto |