| Message ID | 1457179087-27604-5-git-send-email-o-takashi@sakamocchi.jp (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Mar 05 Takashi Sakamoto wrote: > +static bool force_two_pcm_support(struct fw_unit *unit) > +{ > + const char *const models[] = { > + /* TC Electronic models. */ > + "StudioKonnekt48", > + /* Focusrite models. */ > + "SAFFIRE PRO 40", > + "LIQUID SAFFIRE 56", > + "SAFFIRE PRO 40 1", > + }; > + char model[32]; > + unsigned int i; > + int err; > + > + err = fw_csr_string(unit->directory, CSR_MODEL, model, sizeof(model)); > + if (err < 0) > + return false; > + > + for (i = 0; i < ARRAY_SIZE(models); i++) { > + if (strcmp(models[i], model) == 0) > + break; > + } > + > + return i < ARRAY_SIZE(models); > +} The model name of my old Saffire PRO 40 is "SAFFIRE_PRO_40", and according to e.g. Alban Bernard on ffado-user, the newer model is "SAFFIRE_PRO_40_1". Saffire 56's name is "LIQUID_SAFFIRE_56" according to https://forum.ubuntuusers.de/topic/focusrite-liquid/.
On Mar 6 2016 00:07, Stefan Richter wrote: > On Mar 05 Takashi Sakamoto wrote: >> +static bool force_two_pcm_support(struct fw_unit *unit) >> +{ >> + const char *const models[] = { >> + /* TC Electronic models. */ >> + "StudioKonnekt48", >> + /* Focusrite models. */ >> + "SAFFIRE PRO 40", >> + "LIQUID SAFFIRE 56", >> + "SAFFIRE PRO 40 1", >> + }; >> + char model[32]; >> + unsigned int i; >> + int err; >> + >> + err = fw_csr_string(unit->directory, CSR_MODEL, model, sizeof(model)); >> + if (err < 0) >> + return false; >> + >> + for (i = 0; i < ARRAY_SIZE(models); i++) { >> + if (strcmp(models[i], model) == 0) >> + break; >> + } >> + >> + return i < ARRAY_SIZE(models); >> +} > > The model name of my old Saffire PRO 40 is "SAFFIRE_PRO_40", and > according to e.g. Alban Bernard on ffado-user, the newer model is > "SAFFIRE_PRO_40_1". Saffire 56's name is "LIQUID_SAFFIRE_56" > according to https://forum.ubuntuusers.de/topic/focusrite-liquid/. OK. Thanks for your correction. I'll include them in next patchset. Well, can this patchset enable snd-dice to drive your Saffire Pro 40 with several isochronous streams? (of cource, the strings should be fixed.) Regards Takashi Sakamoto
On Mar 06 Takashi Sakamoto wrote: > On Mar 6 2016 00:07, Stefan Richter wrote: > > On Mar 05 Takashi Sakamoto wrote: > >> +static bool force_two_pcm_support(struct fw_unit *unit) > >> +{ > >> + const char *const models[] = { > >> + /* TC Electronic models. */ > >> + "StudioKonnekt48", > >> + /* Focusrite models. */ > >> + "SAFFIRE PRO 40", > >> + "LIQUID SAFFIRE 56", > >> + "SAFFIRE PRO 40 1", > >> + }; > >> + char model[32]; > >> + unsigned int i; > >> + int err; > >> + > >> + err = fw_csr_string(unit->directory, CSR_MODEL, model, sizeof(model)); > >> + if (err < 0) > >> + return false; > >> + > >> + for (i = 0; i < ARRAY_SIZE(models); i++) { > >> + if (strcmp(models[i], model) == 0) > >> + break; > >> + } > >> + > >> + return i < ARRAY_SIZE(models); > >> +} > > > > The model name of my old Saffire PRO 40 is "SAFFIRE_PRO_40", and > > according to e.g. Alban Bernard on ffado-user, the newer model is > > "SAFFIRE_PRO_40_1". Saffire 56's name is "LIQUID_SAFFIRE_56" > > according to https://forum.ubuntuusers.de/topic/focusrite-liquid/. > > OK. Thanks for your correction. I'll include them in next patchset. > > Well, can this patchset enable snd-dice to drive your Saffire Pro 40 > with several isochronous streams? (of cource, the strings should be fixed.) I did a first few tests on 4.5.0-rc6 now. Hardware is Saffire Pro 40 and a XIO2213B OHCI card. I first cherry-picked the following patches from tiwai/sound.git: ALSA: dice: limit to current sampling transfer frequency ALSA: dice: limit stream to current sampling transfer frequency. ALSA: dice: add MIDI ports according to current number of MIDI substreams ALSA: dice: get the number of MBLA data channel at opening PCM substream ALSA: dice: purge generating channel cache ALSA: dice: ensure phase lock before starting streaming ALSA: dice: change notification mask to detect lock status change ALSA: dice: old firmware optimization for Dice notification ALSA: dice: drop duplex streams synchronization to transfer own time stamps I then applied the current 4 patches, with underscores inserted into the model names in patch 4/4. $ arecord -l [...] card 2: Pro4000dd28 [Pro40-00dd28], device 0: DICE [Pro40-00dd28] Subdevices: 2/2 Subdevice #0: subdevice #0 Subdevice #1: subdevice #1 $ aplay -l [...] card 2: Pro4000dd28 [Pro40-00dd28], device 0: DICE [Pro40-00dd28] Subdevices: 2/2 Subdevice #0: subdevice #0 Subdevice #1: subdevice #1 I tested capture and playback at 44100 and 48000 Hz at both subdevices, i.e. on plughw:2,0,0 and plughw:2,0,1 and it seems to work. I only really checked subdevice 0 with I/O other than silence because I am not currently prepared to ADAT. (As you remember there are only ADAT channels on the second stream. Given some time I can probably arrange for another ADAT capable device to transmit and receive via ADAT.) Then I also tried 88200 and 96000 Hz. This gives 16+16 channels at subdevice #0 like it should, and capture works, but playback is mute. I have not yet checked whether the muted playback at 88200/96000 is a consequence of these 4 new patches, or has been introduced earlier, or has always been the case with snd-dice. (I haven't done many systematic tests with the Pro 40 and snd-dice yet. If I unload snd-dice and use FFADO, playback at 88200/96000 works.) Furthermore I did a few quick tests with the entire patchset and Saffire PRO 24 (which uses only 1+1 transmitter+receiver, and consequently is shown only as 1+1 subdevice). I tried 48000 and 96000 Hz, and capture and playback works at both sampling rates. IOW the PRO 40's muting problem is not afflicting the PRO 24. Next thing for me to do will be to remove patches and figure out whether a previous driver revision gives me unmuted playback at 96000 Hz on the PRO 40.
On Mar 06 Stefan Richter wrote: [...] > Then I also tried 88200 and 96000 Hz. This gives 16+16 channels at > subdevice #0 like it should, and capture works, but playback is mute. [...] > Next thing for me to do will be to remove patches and figure out whether > a previous driver revision gives me unmuted playback at 96000 Hz on the > PRO 40. Plain v4.5-rc6 gave me unmuted playback at 88200/96000 Hz once, but it was distorted by some sort of high clinking. Other times plain v4.5-rc6 had muted playback at 88200/96000 Hz too. I tested with mplayer+jack+alsa, audacious+jack+alsa, and audacious+alsa.
Hi Stefan, On Mar 7 2016 7:55, Stefan Richter wrote: > $ arecord -l > [...] > card 2: Pro4000dd28 [Pro40-00dd28], device 0: DICE [Pro40-00dd28] > Subdevices: 2/2 > Subdevice #0: subdevice #0 > Subdevice #1: subdevice #1 > $ aplay -l > [...] > card 2: Pro4000dd28 [Pro40-00dd28], device 0: DICE [Pro40-00dd28] > Subdevices: 2/2 > Subdevice #0: subdevice #0 > Subdevice #1: subdevice #1 > > I tested capture and playback at 44100 and 48000 Hz at both > subdevices, i.e. on plughw:2,0,0 and plughw:2,0,1 and it seems to > work. I only really checked subdevice 0 with I/O other than silence > because I am not currently prepared to ADAT. (As you remember there > are only ADAT channels on the second stream. Given some time I can > probably arrange for another ADAT capable device to transmit and > receive via ADAT.) > > Then I also tried 88200 and 96000 Hz. This gives 16+16 channels at > subdevice #0 like it should, and capture works, but playback is mute. > > I have not yet checked whether the muted playback at 88200/96000 is a > consequence of these 4 new patches, or has been introduced earlier, > or has always been the case with snd-dice. (I haven't done many > systematic tests with the Pro 40 and snd-dice yet. If I unload > snd-dice and use FFADO, playback at 88200/96000 works.) > > Furthermore I did a few quick tests with the entire patchset and > Saffire PRO 24 (which uses only 1+1 transmitter+receiver, and > consequently is shown only as 1+1 subdevice). I tried 48000 and > 96000 Hz, and capture and playback works at both sampling rates. IOW > the PRO 40's muting problem is not afflicting the PRO 24. On Mar 7 2016 09:24, Stefan Richter wrote: > On Mar 06 Stefan Richter wrote: > [...] >> Then I also tried 88200 and 96000 Hz. This gives 16+16 channels at >> subdevice #0 like it should, and capture works, but playback is mute. > [...] >> Next thing for me to do will be to remove patches and figure out whether >> a previous driver revision gives me unmuted playback at 96000 Hz on the >> PRO 40. > > Plain v4.5-rc6 gave me unmuted playback at 88200/96000 Hz once, but it was > distorted by some sort of high clinking. Other times plain v4.5-rc6 had > muted playback at 88200/96000 Hz too. > > I tested with mplayer+jack+alsa, audacious+jack+alsa, and > audacious+alsa. Thanks for your report. Totally: * The patched snd-dice still works fine with Saffire Pro 24. * The pached snd-dice successfully manages several isochronous streams without code bugs (i.e. kernel NULL pointer dereference or continuous locking). * The pached snd-dice still has mute issue for Saffire Pro 40. Anyway, the result cannot block applying this patchset for 4.6. I'll post it in this night for merging. Well, about the mute issue, I have no idea to fix it at all. At least, for my test units, the patched snd-dice works fine without such issues. Therefore, it's nearly model-dependent issue and I have no way to do for it. FYI, I tested with: * OHCI 1394 host controllers * VIA VT6315 * TI XIO2213 * Dice II units * TC Electronic ImpactTwin * TC Electronic Konnekt24D * TC Electronic Konnekt8 * Dice Jr. units * TC Electronic DesktopKonnect6 * Dice Mini units * Focusrite Saffire Pro 26 Regards Takashi Sakamoto
On Mar 7 2016 22:43, Stefan Richter wrote: > On Mar 07 Takashi Sakamoto wrote: >> Thanks for your report. Totally: >> * The patched snd-dice still works fine with Saffire Pro 24. >> * The pached snd-dice successfully manages several isochronous streams >> without code bugs (i.e. kernel NULL pointer dereference or >> continuous locking) with Saffire Pro 24/40. >> * The pached snd-dice still has mute issue with Saffire Pro 40. > > I concur. While I was only able to perform just a few tests yet, there > doesn't appear to be any regression, and this patchset adds support for > the previously inaccessible channels at the second transmitter and > receiver. > >> Anyway, the result cannot block applying this patchset for 4.6. I'll >> post it in this night for merging. > > Thanks. I posted. Thanks for your test ;) >> Well, about the mute issue, I have no idea to fix it at all. At least, >> for my test units, the patched snd-dice works fine without such issues. >> Therefore, it's nearly model-dependent issue and I have no way to do for >> it. FYI, I tested with: >> * OHCI 1394 host controllers >> * VIA VT6315 >> * TI XIO2213 >> * Dice II units >> * TC Electronic ImpactTwin >> * TC Electronic Konnekt24D >> * TC Electronic Konnekt8 >> * Dice Jr. units >> * TC Electronic DesktopKonnect6 >> * Dice Mini units >> * Focusrite Saffire Pro 26 > > FWIW, Saffire PRO 24 and 40 are based on Dice Junior according to FFADO's > device database. If desired I could open up my 24 and 40 to check. If you don't mind it, please. (Because once opening your unit, usually, you cannot get repair service from sellers.) And I wrote wrong for Dice Jr./Mini units. Correctly: * Dice Jr. units * TC Electronic DesktopKonnect6 * Focusrite Saffire Pro 26 * I have no units with Dice Mini (Oh...). Anyway, all of my units with Dice Jr. works fine. So we can judge that Pro 40 has its own quirk which we don't know. > Furthermore FYI, the FFADO userspace streaming driver has got the following > two known issues with the PRO 40: > http://subversion.ffado.org/ticket/326 > playback at 96 kHz is choppy (but fine at 44.1, 48, 88.2 kHz; > reproduced by multiple users, 100% reproducible by myself too) > http://subversion.ffado.org/ticket/372 > MIDI playback problem (perhaps dependent on firmware revision; > cannot reproduce this myself due to lack of MIDI equipment) Hm. With a lack of something like packet dump or detailed case-investigation, I can do nothing for the unit. I have no fashion to lost my time for meaningless talks, sorry. For our information, I put your result of hinawa-dice-common-cui from Saffire Pro 40. (meaningless lines are omitted.) $ ./hinawa-dice-common-cui 00130e040140dd28 current-status owner address: ffc1000100000000 global enabled: False clock status: locked: 1 nominal: 48000 clock source detection: locked: slip: measured rate: 48000 dice version: 1.0.12.0 latest notification: 0x00000010 clock source: Internal sampling rate: 48000 nickname: Pro40-00dd28 Transmitted streams: Stream 0: iso-channel: 4294967295 speed: 2 pcm: 10 midi: 1 iec60958: caps: 0 enable: 0 formation: 0: IP 1 1: IP 2 2: IP 3 3: IP 4 4: IP 5 5: IP 6 6: IP 7 7: IP 8 8: SPDIF L 9: SPDIF R Stream 1: iso-channel: 4294967295 speed: 2 pcm: 10 midi: 0 iec60958: caps: 0 enable: 0 formation: 0: ADAT 1 1: ADAT 2 2: ADAT 3 3: ADAT 4 4: ADAT 5 5: ADAT 6 6: ADAT 7 7: ADAT 8 8: Loop 1 9: Loop 2 Received streams: Stream 0: iso-channel: 4294967295 start: 0 pcm: 12 midi: 1 iec60958: caps: 0 enable: 0 formation: 0: Mon 1 1: Mon 2 2: Line 3 3: Line 4 4: Line 5 5: Line 6 6: Line 7 7: Line 8 8: Line 9 9: Line 10 10: SPDIF L 11: SPDIF R Stream 1: iso-channel: 4294967295 start: 0 pcm: 8 midi: 0 iec60958: caps: 0 enable: 0 formation: 0: ADAT 1 1: ADAT 2 2: ADAT 3 3: ADAT 4 4: ADAT 5 5: ADAT 6 6: ADAT 7 7: ADAT 8 Synchronization infomation: clock-source: Internal locked: 1 sampling-rate: 48000 ADAT: data-bits: 0 no-data: 1 $ ./hinawa-dice-common-cui 00130e040140dd28 sampling-rate set 96000 $ ./hinawa-dice-common-cui 00130e040140dd28 current-status owner address: ffc1000100000000 global enabled: False clock status: locked: 1 nominal: 96000 clock source detection: locked: slip: measured rate: 96000 dice version: 1.0.12.0 latest notification: 0x00000010 clock source: Internal sampling rate: 96000 nickname: Pro40-00dd28 Transmitted streams: Stream 0: iso-channel: 4294967295 speed: 2 pcm: 16 midi: 1 iec60958: caps: 0 enable: 0 formation: 0: IP 1 1: IP 2 2: IP 3 3: IP 4 4: IP 5 5: IP 6 6: IP 7 7: IP 8 8: SPDIF L 9: SPDIF R 10: ADAT 1 11: ADAT 2 12: ADAT 3 13: ADAT 4 14: Loop 1 15: Loop 2 Received streams: Stream 0: iso-channel: 4294967295 start: 0 pcm: 16 midi: 1 iec60958: caps: 0 enable: 0 formation: 0: Mon 1 1: Mon 2 2: Line 3 3: Line 4 4: Line 5 5: Line 6 6: Line 7 7: Line 8 8: Line 9 9: Line 10 10: SPDIF L 11: SPDIF R 12: ADAT 1 13: ADAT 2 14: ADAT 3 15: ADAT 4 Synchronization infomation: clock-source: Internal locked: 1 sampling-rate: 96000 ADAT: data-bits: 0 no-data: 1 Regards Takashi Sakamoto
On Mar 07 Takashi Sakamoto wrote: > On Mar 7 2016 22:43, Stefan Richter wrote: > > On Mar 07 Takashi Sakamoto wrote: > >> * Dice II units > >> * TC Electronic ImpactTwin > >> * TC Electronic Konnekt24D > >> * TC Electronic Konnekt8 > >> * Dice Jr. units > >> * TC Electronic DesktopKonnect6 > >> * Dice Mini units > >> * Focusrite Saffire Pro 26 > > > > FWIW, Saffire PRO 24 and 40 are based on Dice Junior according to FFADO's > > device database. If desired I could open up my 24 and 40 to check. > > If you don't mind it, please. > (Because once opening your unit, usually, you cannot get repair service > from sellers.) > > And I wrote wrong for Dice Jr./Mini units. Correctly: > * Dice Jr. units > * TC Electronic DesktopKonnect6 > * Focusrite Saffire Pro 26 > * I have no units with Dice Mini (Oh...). > > Anyway, all of my units with Dice Jr. works fine. So we can judge that > Pro 40 has its own quirk which we don't know. Written on the Dice chip in my Saffire PRO 24, purchased in 2010: TCD2210 K34FAAB C0906 So that's a DICE Mini. And the Saffire PRO 40, purchased in early 2015: TCD2220 K8GVUF A1246 i.e. DICE JR.
Just a reminder in case it gets overlooked. The new Focusrite Saffire Pro 40, as of a few months ago, is now a Dice III. Focusrite were going to contact me again about that "after Christmas", but despite a couple of reminders, I've heard nothing more. Gordon. On Sat, 2016-04-09 at 18:34 +0200, Stefan Richter wrote: > On Mar 07 Takashi Sakamoto wrote: > > On Mar 7 2016 22:43, Stefan Richter wrote: > > > On Mar 07 Takashi Sakamoto wrote: > > >> * Dice II units > > >> * TC Electronic ImpactTwin > > >> * TC Electronic Konnekt24D > > >> * TC Electronic Konnekt8 > > >> * Dice Jr. units > > >> * TC Electronic DesktopKonnect6 > > >> * Dice Mini units > > >> * Focusrite Saffire Pro 26 > > > > > > FWIW, Saffire PRO 24 and 40 are based on Dice Junior according to FFADO's > > > device database. If desired I could open up my 24 and 40 to check. > > > > If you don't mind it, please. > > (Because once opening your unit, usually, you cannot get repair service > > from sellers.) > > > > And I wrote wrong for Dice Jr./Mini units. Correctly: > > * Dice Jr. units > > * TC Electronic DesktopKonnect6 > > * Focusrite Saffire Pro 26 > > * I have no units with Dice Mini (Oh...). > > > > Anyway, all of my units with Dice Jr. works fine. So we can judge that > > Pro 40 has its own quirk which we don't know. > > Written on the Dice chip in my Saffire PRO 24, purchased in 2010: > > TCD2210 > K34FAAB > C0906 > > So that's a DICE Mini. > > And the Saffire PRO 40, purchased in early 2015: > > TCD2220 > K8GVUF > A1246 > > i.e. DICE JR.
Hi Stefan, On Apr 10 2016 01:34, Stefan Richter wrote: > On Mar 07 Takashi Sakamoto wrote: >> On Mar 7 2016 22:43, Stefan Richter wrote: >>> On Mar 07 Takashi Sakamoto wrote: >>>> * Dice II units >>>> * TC Electronic ImpactTwin >>>> * TC Electronic Konnekt24D >>>> * TC Electronic Konnekt8 >>>> * Dice Jr. units >>>> * TC Electronic DesktopKonnect6 >>>> * Dice Mini units >>>> * Focusrite Saffire Pro 26 >>> >>> FWIW, Saffire PRO 24 and 40 are based on Dice Junior according to FFADO's >>> device database. If desired I could open up my 24 and 40 to check. >> >> If you don't mind it, please. >> (Because once opening your unit, usually, you cannot get repair service >> from sellers.) >> >> And I wrote wrong for Dice Jr./Mini units. Correctly: >> * Dice Jr. units >> * TC Electronic DesktopKonnect6 >> * Focusrite Saffire Pro 26 >> * I have no units with Dice Mini (Oh...). >> >> Anyway, all of my units with Dice Jr. works fine. So we can judge that >> Pro 40 has its own quirk which we don't know. > > Written on the Dice chip in my Saffire PRO 24, purchased in 2010: > > TCD2210 > K34FAAB > C0906 > > So that's a DICE Mini. > > And the Saffire PRO 40, purchased in early 2015: > > TCD2220 > K8GVUF > A1246 > > i.e. DICE JR. Thanks for your confirmation. The database of FFADO project includes the wrongs for some models, therefore it's better for us to get such evidences. Recently I got PreSonus FireStudio Mobile from used-market. It has TCD2210 (Dice Mini). I've started to read packet dumps for Dice ASICs except for TCD3070-CH, on Windows/Linux (ALSA). Well, would you please get packet dumps with your models? Especially with SaffirePro 40 because current ALSA firewire stack cannot make it generate correct sounds, as long as you tested. I need the dumps under conditions below: - From the beginning of starting packet streaming. - During seven seconds after the beginning, at least. - Including the contents of asynchronous packets for cycle start packet. - Including the contents of isochronous packets for all of used channels. At least: - The length of payload. - The number of channel - The node IDs for ishcchronous source and destination - Two quadlets of CIP header. - A condition that your unit is driven by Windows driver. - At both of 44.1/48.0kHz For example, this is a sample got by my protocol analyzer (not nosy, I have no cards with PCILynx). rel. time (uSec),type,source ID,dest. ID,offset,label,retry code,response code,priority,data length,quadlet data,tag,channel,sync.,speed,acknowledge,data 0.000,CycleStart,0xFFC2,0xFFFF,0xFFFFF0000200,0,retry_1,,15,,0xE371B034,,,,100,, 2.614,Streaming,,,,,,,,8,,1,0,0,400,,0x020F0028,0x9001FFFF,0x570A5DF9 122.375,CycleStart,0xFFC2,0xFFFF,0xFFFFF0000200,0,retry_1,,15,,0xE371C034,,,,100,, 2.614,Streaming,,,,,,,,488,,1,0,0,400,,0x020F0028,0x9001DAB9, (CIP data) 122.386,CycleStart,0xFFC2,0xFFFF,0xFFFFF0000200,0,retry_1,,15,,0xE371D034,,,,100,, 2.614,Streaming,,,,,,,,488,,1,0,0,400,,0x020F0030,0x9001F423, (CIP data) 122.386,CycleStart,0xFFC2,0xFFFF,0xFFFFF0000200,0,retry_1,,15,,0xE371E034,,,,100,, 2.614,Streaming,,,,,,,,8,,1,0,0,400,,0x020F0038,0x9001FFFF,0xD4D853F5 122.386,CycleStart,0xFFC2,0xFFFF,0xFFFFF0000200,0,retry_1,,15,,0xE371F034,,,,100,, 2.614,Streaming,,,,,,,,488,,1,0,0,400,,0x020F0038,0x9001098E, (CIP data) ... When I run my parser written by Python3, I got enough information: ['0xE371B034', '0x020F0028', '0x9001FFFF', 2795258932, 0, 0] ['0xE371C034', '0x020F0028', '0x9001DAB9', 2795262004, 2795267769, 5765] ['0xE371D034', '0x020F0030', '0x9001F423', 2795265076, 2795272227, 7151, 4458] ['0xE371E034', '0x020F0038', '0x9001FFFF', 2795268148, 0, 0] ['0xE371F034', '0x020F0038', '0x9001098E', 2795271220, 2795276686, 5466, 4459] ... Legend: - CycleStart - CIP header 0 - CIP header 1 - CycleStart(tick) - presentation timestamp(tick) - subtraction between CycleStart and presentation timestamp (tick) - subtraction between previous/current presentation timestamp(tick) Currently, I can find some differences between Dice ASICs: - The ASIC for Dice II transfers/receives packets with less transfer-delay than the value defined in IEC 61883-6. But packets for the other ASICs are compliant to it. I don't investigate the sequence of the length of CIP data yet. Regards Takashi Sakamoto
On Apr 12 Takashi Sakamoto wrote: > would you please get packet dumps with your models? Especially > with SaffirePro 40 [...] I will, but it may take a while until I manage to do so.
diff --git a/sound/firewire/dice/dice-pcm.c b/sound/firewire/dice/dice-pcm.c index 3762bd3..532de99 100644 --- a/sound/firewire/dice/dice-pcm.c +++ b/sound/firewire/dice/dice-pcm.c @@ -332,16 +332,22 @@ int snd_dice_create_pcm(struct snd_dice *dice) int err; /* Check whether PCM substreams are required. */ - capture = playback = 0; - err = snd_dice_transaction_read_tx(dice, TX_NUMBER, ®, sizeof(reg)); - if (err < 0) - return err; - capture = min_t(unsigned int, be32_to_cpu(reg), MAX_STREAMS); + if (dice->force_two_pcms) { + capture = playback = 2; + } else { + capture = playback = 0; + err = snd_dice_transaction_read_tx(dice, TX_NUMBER, ®, + sizeof(reg)); + if (err < 0) + return err; + capture = min_t(unsigned int, be32_to_cpu(reg), MAX_STREAMS); - err = snd_dice_transaction_read_rx(dice, RX_NUMBER, ®, sizeof(reg)); - if (err < 0) - return err; - playback = min_t(unsigned int, be32_to_cpu(reg), MAX_STREAMS); + err = snd_dice_transaction_read_rx(dice, RX_NUMBER, ®, + sizeof(reg)); + if (err < 0) + return err; + playback = min_t(unsigned int, be32_to_cpu(reg), MAX_STREAMS); + } err = snd_pcm_new(dice->card, "DICE", 0, playback, capture, &pcm); if (err < 0) diff --git a/sound/firewire/dice/dice.c b/sound/firewire/dice/dice.c index f7303a6..215b6cc 100644 --- a/sound/firewire/dice/dice.c +++ b/sound/firewire/dice/dice.c @@ -13,6 +13,8 @@ MODULE_LICENSE("GPL v2"); #define OUI_WEISS 0x001c6a #define OUI_LOUD 0x000ff2 +#define OUI_FOCUSRITE 0x00130e +#define OUI_TCELECTRONIC 0x001486 #define DICE_CATEGORY_ID 0x04 #define WEISS_CATEGORY_ID 0x00 @@ -20,6 +22,36 @@ MODULE_LICENSE("GPL v2"); #define PROBE_DELAY_MS (2 * MSEC_PER_SEC) +/* + * Some models support several isochronous channels, while these streams are not + * always available. In this case, add the model name to this list. + */ +static bool force_two_pcm_support(struct fw_unit *unit) +{ + const char *const models[] = { + /* TC Electronic models. */ + "StudioKonnekt48", + /* Focusrite models. */ + "SAFFIRE PRO 40", + "LIQUID SAFFIRE 56", + "SAFFIRE PRO 40 1", + }; + char model[32]; + unsigned int i; + int err; + + err = fw_csr_string(unit->directory, CSR_MODEL, model, sizeof(model)); + if (err < 0) + return false; + + for (i = 0; i < ARRAY_SIZE(models); i++) { + if (strcmp(models[i], model) == 0) + break; + } + + return i < ARRAY_SIZE(models); +} + static int check_dice_category(struct fw_unit *unit) { struct fw_device *device = fw_parent_device(unit); @@ -44,6 +76,12 @@ static int check_dice_category(struct fw_unit *unit) break; } } + + if (vendor == OUI_FOCUSRITE || vendor == OUI_TCELECTRONIC) { + if (force_two_pcm_support(unit)) + return 0; + } + if (vendor == OUI_WEISS) category = WEISS_CATEGORY_ID; else if (vendor == OUI_LOUD) @@ -150,6 +188,9 @@ static void do_registration(struct work_struct *work) if (err < 0) return; + if (force_two_pcm_support(dice->unit)) + dice->force_two_pcms = true; + err = snd_dice_transaction_init(dice); if (err < 0) goto error; diff --git a/sound/firewire/dice/dice.h b/sound/firewire/dice/dice.h index 8fba87d..e6c0785 100644 --- a/sound/firewire/dice/dice.h +++ b/sound/firewire/dice/dice.h @@ -97,6 +97,8 @@ struct snd_dice { bool global_enabled; struct completion clock_accepted; unsigned int substreams_counter; + + bool force_two_pcms; }; enum snd_dice_addr_type {
Some models reduce the number of available isochronous streams for higher sampling transfer frequency. Such models bring an issue about how to add PCM substreams. When at lower sampling transfer frequency, the models reports whole available streams, thus this driver can add enough number of PCM substreams at probing time. On the other hand, at higher sampling transfer frequency, this driver can just add reduced number of PCM substreams. After probed, even if the sampling transfer frequency is changed to lower rate, fewer PCM substreams are actually available. This is inconvenience. For the reason, this commit adds a list so that this driver assume models on the list to have two pairs of PCM substreams. This list keeps the name of model in which the number of available streams differs depending on sampling transfer frequency. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> --- sound/firewire/dice/dice-pcm.c | 24 +++++++++++++++--------- sound/firewire/dice/dice.c | 41 +++++++++++++++++++++++++++++++++++++++++ sound/firewire/dice/dice.h | 2 ++ 3 files changed, 58 insertions(+), 9 deletions(-)