From: Damien Z. <dam...@gm...> - 2012-12-21 03:34:52
|
Hi all, Not sure if this is the right place to post this: I have managed to patch Clemens' firewire-kernel-streaming driver to provide playback for Digidesign 003 Rack. It requires some special manufacturer-only snd_fw_transaction commands to configure the device which I have nutted out. Actually I created a new file and compiled a separate driver based on dice.c, (although I realise this is probably not the best way to get it accepted into the codebase). It works very well with aplay except for a slight hiss in the right channel, but using jackd -d alsa -d hw:0 -r44100 -n2 does not work. Jack initialises the stream and then loses sync within a second or so. Jack continues to run without error but no sound can play. Any ideas? Regards, Damien |
From: Clemens L. <cl...@la...> - 2012-12-21 09:20:24
|
Damien Zammit wrote: >I have managed to patch Clemens' firewire-kernel-streaming driver to >provide playback for Digidesign 003 Rack. >It requires some special manufacturer-only snd_fw_transaction commands >to configure the device which I have nutted out. > >It works very well with aplay except for a slight hiss in the right >channel, but using jackd -d alsa -d hw:0 -r44100 -n2 does not work. >Jack initialises the stream and then loses sync within a second or so. Can this device actually sync to the PC, i.e., is a clock source "RX" listed in /proc/asound/card*/dice? Regards, Clemens |
From: Damien Z. <dam...@gm...> - 2012-12-22 01:03:47
|
Hi Clemens, Thanks so much for your work on the alsa firewire stuff, it is progressing! On 21 December 2012 20:20, Clemens Ladisch <cl...@la...> wrote: > Can this device actually sync to the PC, I'm not sure. > i.e., is a clock source "RX" listed in > /proc/asound/card*/dice? No, I commented all that "proc" part of your code out because it doesnt seem to respond as a dice chip. I don't know if any of the snd_fw_transaction commands you use in your code apply to this device. Having bus snooped the windows driver it doesn't seem to use any of your commands, the register offsets don't really make sense with what I have observed but I haven't really analysed your ones carefully. I doubt the 003 has the ability to autodetect parameters such as number of channels etc. >From my own firewire bus analysis: the 003 has two main registers: A stream management register and a samplerate selection register. It also has some internal routing, zero-latency mix registers to monitor any of the inputs at any of the first two main outputs (maybe more) and a special midi register to enable the device to expect a midi quadlet as the first data quadlet in the playback stream. I am grateful for the assistance provided by rgareus in #jack who helped me yesterday nut out some of AMDTP. We came to the conclusion that integer multiples of 48000Hz audio are good for firewire transport (due to the timing of the firewire packets 1/8000 seconds per packet). I believe your code that handles the non-standard rates such as integer multiples of 44100Hz does not work well on the 003 for some reason. 48k and 96k play very well apart from slight hiss (due to some unknown spillage between channels and how midi might be handled?). The only thing left to do for this device is to work out where this hiss is coming from and work out why the streams drop after a few seconds of playback. I am using a 00:0e.0 FireWire (IEEE 1394) [0c00]: VIA Technologies, Inc. VT6306/7/8 [Fire II(M)] IEEE 1394 OHCI Controller [1106:3044] (rev 80) in a very old machine with only 512Mb ram and a K8 processor. I'm not sure if this is to blame, but I would like to buy a pci-e 1394a controller for my solid main machine which is much more powerful. Can anyone recommend a good PCI-E 1394a card that isnt too expensive? My only regular PCI slot is taken up with my PCILynx2 card. Thanks, Damien |
From: Jonathan W. <jw...@ju...> - 2012-12-22 01:12:25
|
Hi Damien > No, I commented all that "proc" part of your code out because it > doesnt seem to respond as a dice chip. I would be somewhat surprised if the 003 used a bog-standard DICE chip. It's therefore not surprising that it's not responding to the DICE commands. If you're not afraid of opening stuff up, you could probably pop the top off the 003 and see what chips are actually in use. At the end of the day though this is likely to only tell you what we already know. :-) > The only thing left to do for this device is to work out where this > hiss is coming from and work out why the streams drop after a few > seconds of playback. > > I am using a 00:0e.0 FireWire (IEEE 1394) [0c00]: VIA Technologies, > Inc. VT6306/7/8 [Fire II(M)] IEEE 1394 OHCI Controller [1106:3044] > (rev 80) > in a very old machine with only 512Mb ram and a K8 processor. I'm not > sure if this is to blame, but I would like to buy a pci-e 1394a > controller for my solid main machine which is much more powerful. If we are talking about a true hiss (that is, broadband noise) then it's almost certainly got nothing to do with your firewire card. It is much more likely to be due to hardware configuration of the 003 itself. For example, a hiss is typically caused by an incorrect gain structure - where a noisy amplifier is given high gain when its design is focused at low to moderate gains. The dropping of the streams may be due to the VIA card. Some VIAs are good and others aren't and I can't recall which camp yours falls into off-hand. Regards jonathan |
From: Damien Z. <dam...@gm...> - 2012-12-22 01:18:58
|
On 22 December 2012 12:12, Jonathan Woithe <jw...@ju...> wrote: > a hiss is typically caused by an incorrect gain structure - where a noisy > amplifier is given high gain when its design is focused at low to moderate > gains. The thing is, when I play zeroes through the playback stream, the device is *dead* silent. As soon as I play something like music, i get hiss that seems to be tainted with the sound of the music. I believe it is MSB leaking into LSB of some channel or something like that. Could it be due to the unknown way midi is handled in the 003? > The dropping of the streams may be due to the VIA card. I hope so. |
From: Damien Z. <dam...@gm...> - 2012-12-22 01:22:03
|
On 22 December 2012 12:18, Damien Zammit <dam...@gm...> wrote: > As soon as I play something like music, i get hiss that seems to be > tainted with the sound of the music. I forgot to mention, it also plays the regular music at regular volume on top of this hiss. |
From: Jonathan W. <jw...@ju...> - 2012-12-22 01:35:58
|
Hi Damien On Sat, Dec 22, 2012 at 12:21:57PM +1100, Damien Zammit wrote: > On 22 December 2012 12:18, Damien Zammit <dam...@gm...> wrote: > > As soon as I play something like music, i get hiss that seems to be > > tainted with the sound of the music. > I forgot to mention, it also plays the regular music at regular volume > on top of this hiss. The source of the his may not be in the music's signal path. If the output from a mis-configured amplifier or functional block (producing hiss) is being mixed with the music signal originating from some other source you would get the symptoms you describe. It all comes down to the internal architecture of the interface, of which I know very little. This obviously isn't the only possible reason - it's just the one which makes more sense to me. If it's a true hiss then the source is most likely analog in nature, but electronics is always surprising. Regards jonathan |
From: Damien Z. <dam...@gm...> - 2012-12-22 02:09:09
|
Hi sorry Jonathan you might get this twice. On 22 December 2012 12:35, Jonathan Woithe <jw...@ju...> wrote: > The source of the his may not be in the music's signal path. If the output > from a mis-configured amplifier or functional block (producing hiss) is > being mixed with the music signal originating from some other source you > would get the symptoms you describe. Okay I will try to snoop the remaining routing registers and clear them all to non-passthrough. With the channels_mask, I tried the following and these settings all had the same effect of allowing playback to function except the marked ones. Can someone please explain how the channels_mask corresponds to iso resource channel numbers. 1...1111 1111 1111 <---- not working 1...1111 1111 1110 1...1111 1111 1100 <---- not working 1...1111 1111 1010 1...1111 1111 0110 1...1111 1110 1110 1...1111 1101 1110 1...1111 1011 1110 1...1111 0111 1110 1...1110 1111 1110 1...1101 1111 1110 1...1011 1111 1110 1...0111 1111 1110 Another thing we discovered was the following: For the playback stream of the 003 and the existing fw alsa driver which I hacked: At 48kHz there are exactly 24 samples per fw packet so 24*1/48000*8000 = 4 At 96kHz there are exactly 48 samples per fw packet so 48*1/96000*8000 = 4 Should this not come out to 1? Where does the extra factor of 4 come into it? Regards, Damien |
From: Stefan R. <st...@s5...> - 2012-12-22 09:53:01
|
On Dec 22 Damien Zammit wrote: > With the channels_mask, I tried the following and these settings all > had the same effect of allowing playback to function except the marked > ones. > Can someone please explain how the channels_mask corresponds to iso > resource channel numbers. > > 1...1111 1111 1111 <---- not working > 1...1111 1111 1110 > 1...1111 1111 1100 <---- not working > 1...1111 1111 1010 > 1...1111 1111 0110 > 1...1111 1110 1110 > 1...1111 1101 1110 > 1...1111 1011 1110 > 1...1111 0111 1110 > 1...1110 1111 1110 > 1...1101 1111 1110 > 1...1011 1111 1110 > 1...0111 1111 1110 sound/firewire/iso-resources.h::fw_iso_resources.channels_mask obviously has the same definition as @channels_mask of drivers/firewire/core-iso.c::fw_iso_resource_manage(): "[fw_iso_resource_manage() a]llocates or deallocates at most one channel out of channels_mask. channels_mask is a bitfield with MSB for channel 63 and LSB for channel 0." Perhaps the 003 Rack's firmware expects a somewhat fixed assignment of channel numbers, e.g. - capture stream always at 0, playback stream always at 1 (in which case it would be impossible to use more than one 003 Rack at the same bus), or - capture stream always at an even channel number, playback stream always at an odd channel number (and perhaps == capture channel number + 1), or - because you did not configure it explicitly, it believes that the capture stream is on channel 0 and, it wants the playback stream on capture channel number + 1. -- Stefan Richter -=====-===-- ==-- =-==- http://arcgraph.de/sr/ |
From: Jonathan W. <jw...@ju...> - 2012-12-22 02:48:52
|
Hi Damien > On 22 December 2012 12:35, Jonathan Woithe <jw...@ju...> wrote: > > The source of the his may not be in the music's signal path. If the output > > from a mis-configured amplifier or functional block (producing hiss) is > > being mixed with the music signal originating from some other source you > > would get the symptoms you describe. > Okay I will try to snoop the remaining routing registers and clear > them all to non-passthrough. That would probably be a good initial plan of attack. > With the channels_mask, I tried the following and these settings all > had the same effect of allowing playback to function except the marked > ones. Which channels_mask is this? If it's part of the 003 protocol then the interpretation would be determined by the device itself. Apologies if this has already been covered in an earlier discussion which I have not seen. > Can someone please explain how the channels_mask corresponds to iso > resource channel numbers. It depends on what channels_mask actually refers to. One potential cause of confusion might be the multiple meaning of "channel" when talking about a firewire interface. Obviously a "channel" can be a physical audio input or output on the device. At the firewire protocol level however, there is also the context of isochronous (iso) channels. These don't really have anything to do with the audio channels of the device. They are a bus construct which is used to identify different data streams on the wire. Most devices use one iso channel to send data to the computer, and one to receive data from the computer. The audio data in a given direction is effectively multiplexed into a single data stream which is sent on a particular firewire iso channel. > 1...1111 1111 1111 <---- not working > 1...1111 1111 1110 > 1...1111 1111 1100 <---- not working > 1...1111 1111 1010 > : There's clearly no obvious pattern here. Assuming this is an audio channel mask associated with the 003 protocol, the only way of reconciling this would be to obtain a greater understanding of what the various bit positions refer to. For example, some devices utilise "write enable" bits in their masks in combination with data bits. In such cases, a given data bit only takes effect if the corresponding write enable bit is set. This can make it challenging to determine the layout of the mask just be throwing data values at it. > Another thing we discovered was the following: > > For the playback stream of the 003 and the existing fw alsa driver > which I hacked: > At 48kHz there are exactly 24 samples per fw packet so 24*1/48000*8000 = 4 > At 96kHz there are exactly 48 samples per fw packet so 48*1/96000*8000 = 4 > > Should this not come out to 1? Where does the extra factor of 4 come into it? I'm not sure what the "24 samples per fw packet" refers to. A total of 24 samples (across all audio channels) seems far too low, unless the 003 only sends and receives data for selected audio channels (most interfaces always send audio data for all possible regardless of whether the software is interested in all channels). If this was a "per audio channel" figure it appears remarkably high. Perhaps the audio streaming of this device works differently to other devices (or at least those I've had direct low-level experience with). Some ideas off the top of my head: 1) Maybe the data stream only ever sends/expects data from audio channels which the driver has explicitly enabled. If such enabling was done in groups of 4 (or you've enabled 4 channels) this may explain your additional factor of 4. That is, perhaps the 24 samples you're seeing at 48 kHz contains data for 4 audio channels. 2) The calculation you did assumes that audio data is sent in every iso cycle. Maybe the 003 skips cycles periodically (most other interfaces do) in order to provide a timing buffer between the computer and the interface's audio clock. Regards jonathan |
From: Damien Z. <dam...@gm...> - 2012-12-22 03:19:26
|
On 22 December 2012 13:48, Jonathan Woithe <jw...@ju...> wrote: > At the firewire protocol > level however, there is also the context of isochronous (iso) channels. Yes I am referring to this, and in particular how the channels_mask parameter in dice.c corresponds to which iso channels are being allocated at the firewire level. >> 1...1111 1111 1111 <---- not working >> 1...1111 1111 1110 >> 1...1111 1111 1100 <---- not working >> 1...1111 1111 1010 >> : > There's clearly no obvious pattern here. There is, I started with FFFF...FFFF that was originally in dice.c and invented the pattern by placing a zero at the LSb and moving a zero through the bit pattern to see which channels would work. But I would like to know the mathematical relationship between the iso channel selection and this mask, it doesn't seem straightforward. > Assuming this is an audio channel > mask associated with the 003 protocol, Sorry for the misunderstanding, it has nothing to do with the 003 protocol, I just put that pattern there as an example of which masks I was trying to use. >> At 48kHz there are exactly 24 samples per fw packet so 24*1/48000*8000 = 4 >> At 96kHz there are exactly 48 samples per fw packet so 48*1/96000*8000 = 4 > I'm not sure what the "24 samples per fw packet" refers to. > If this was a "per audio channel" figure it > appears remarkably high. Yes it is per audio channel and I don't know why it sends so much data because it probably doesnt need to? Technically it only needs 1/4 of this according to my calculation above. I am likely doing something wrong in the driver. However, the Windows driver sends 28 samples per audio channel (18 of them + 1x midi = 19 quadlets) per iso packet for 48kHz mode! I am really confused and not sure whether the number of samples must match what the device expects (as per windows), or whether it doesn't matter if i send it less samples per packet so long as the total number of quadlets is an integer multiple of the total number of audio channels (excluding the 8 header bytes). Does anyone know if this is configurable in dice.c? > 2) The calculation you did assumes that audio data is sent in every iso > cycle. Maybe the 003 skips cycles periodically (most other interfaces > do) in order to provide a timing buffer between the computer and the > interface's audio clock. I have not seen any iso missing cycles in my iso dumps. I believe this could be considered a loss of sync for the 003 since there is a register command that resets the clock and it is always called right before iso streams start. Damien |
From: Damien Z. <dam...@gm...> - 2012-12-22 05:17:00
|
003 Rack iso packet descriptions: PT 48kHz mode: PLAYBACK: 19 channels (incl midi x1) 28 samples /ch /packet x8 packets, 20 samples /ch /packet x8 packets. repeat RECORDING: 19 channels 24 samples /ch /packet PT 96kHz mode: PLAYBACK: 11 channels (incl midi x1, ADAT disabled) 56 samples /ch /packet x2 packets, 44 samples /ch /packet x6 packets, 56 samples /ch /packet x3 packets, 44 samples /ch /packet x5 packets, 56 samples /ch /packet x3 packets, 44 samples /ch /packet x5 packets. repeat RECORDING: 11 channels (incl midi x1, ADAT disabled) 48 samples /ch /packet Does this look familiar? Damien |
From: Damien Z. <dam...@gm...> - 2012-12-23 23:13:34
|
On 24 December 2012 00:47, Stefan Richter <st...@s5...> wrote: > If bit m is 0, firewire-core shall ignore whether that channel is still > available and not attempt to allocate it. Thanks Stefan for the clarification. The 003 only seems to play anything when I force it to use 1 as the playback channel, ie using a mask of 0x00000000 00000002. This means that only 1x 003 can be used on the bus at once as you suggested, Stefan. It is possibly a design flaw. Damien |
From: Jonathan W. <jw...@ju...> - 2012-12-24 05:40:09
|
On Mon, Dec 24, 2012 at 10:13:23AM +1100, Damien Zammit wrote: > On 24 December 2012 00:47, Stefan Richter <st...@s5...> wrote: > > If bit m is 0, firewire-core shall ignore whether that channel is still > > available and not attempt to allocate it. > > Thanks Stefan for the clarification. Indeed - that all seems to make sense now. > The 003 only seems to play anything when I force it to use 1 as the > playback channel, > ie using a mask of 0x00000000 00000002. Interesting. > This means that only 1x 003 can be used on the bus at once as you > suggested, Stefan. When using 003s on systems supported by digidesign (now avid) was it possible to use more than one 003 on the bus? > It is possibly a design flaw. Or a deliberate decision by digidesign to only support a single interface on a given bus. Nothing would surprise me. I don't know how many audio channels are supported by the 003, but another line of reasoning might have been that there was insufficient bandwidth under ff400 to support more than one 003, so digidesign couldn't be bothered supporting more than one 003 per bus. Of course limiting the iso channel like this pretty much means you can't have anything else on the bus and guarantee reliable initialisation of the 003. Again, this might well have been digidesign's idea: they wanted the 003 on its own bus with nothing else to interfere. I do seem to vaguely recall reading something like this somewhere: that digidesign used firewire for the data transport, but treated that bus as a private bus between their driver and the 003. Manufacturers do really strange things, and everything suggested above would be a real possibility in my experience. It would be wrong to assume it was an inadvertent design flaw (but a deliberate design flaw would be entirely possible). Regards jonathan |
From: Clemens L. <cl...@la...> - 2012-12-24 08:07:37
|
Damien Zammit wrote: >The 003 only seems to play anything when I force it to use 1 as the >playback channel, It's possible that this is the default channel setting that simply has not been changed so far. Regards, Clemens |
From: Damien Z. <dam...@gm...> - 2012-12-24 13:33:49
|
Another thing we discovered yesterday, (Robin Gareus and I having a discussion in #jack): The ALSA backend of jack doesn't seem to support the RW_INTERLEAVED method of memory access, but has MMAP_INTERLEAVED and MMAP_COMPLEX (?) instead. We think this is causing the playback stream to drop when the ALSA experimental firewire streaming driver is used with jack, but I'm not entirely sure because my VIA chipset firewire controller is behaving temperamentally even without jack at all. I am looking forward to my TI chipset fw800 controller to arrive in the next couple of weeks so I can do more testing. The remaining issue I have discovered with the 003 is that when audio is played through pcm channel N, there is leakage at low volume into channel N+1, and after channel 18, this leakage wraps around back into channel 1. This is simply a better description of the 'hissing' noise I was talking about earlier. I am starting to wonder if the interpretation of MIDI quadlets in amdtp.c needs customisation for the 003, but I am having trouble working out how a non integer number of quadlets could be interpreted as crosstalk when the data quadlets seem to be broken into groups that appear to be standard AMDTP. Regards, Damien |
From: Damien Z. <dam...@gm...> - 2012-12-24 13:42:12
|
On 25 December 2012 00:33, Damien Zammit <dam...@gm...> wrote: >I am having trouble > working out how a non integer number of quadlets could be interpreted > as crosstalk when the data quadlets seem to be broken into groups that > appear to be standard AMDTP. Sorry that made no sense. What I meant was, I have observed iso dumps during playback on the 003 in windows that consist of perfectly aligned quadlets. Therefore, there are no missing or extra bits in the 003 protocol that could be accidently misaligned by amdtp.c since the protocol seems to follow the standard. (Except that the midi quadlets are at the front which Clemens said is unusual). Therefore I am having trouble working out how a misalignment could occur causing this channel leakage. Regards, Damien |