[alsa-devel] MIDI on ice1724 - long delays

[Takashi Iwai]

At Wed, 23 Apr 2008 22:19:04 +0200,
Pavel Hofman wrote:
> 
> Pavel Hofman wrote:
> > Takashi Iwai wrote:
> >> At Tue, 22 Apr 2008 22:23:55 +0200,
> >> Pavel Hofman wrote:
> >>> Hi,
> >>>
> > ...........
> >>> After the playback stops, the interrupts are gone too. It seems as if 
> >>> the playback interrupt initiates the MPU TX interrupt.
> >>>
> >>> If we could avoid generating the MPU TX interrupt during regular 
> >>> playback, I believe the major problem would be resolved.
> >>>
> >>> Even if I mask the interrupts (CCS01) and do not explicitly unmask them 
> >>> (according to proc ice1724 the CCS01 register stays at 0xa0), the 
> >>> interrupt gets generated.
> >> OK, then the simplest way would be to just ignore the TX bit at the
> >> second or later check.
> >>
> >> How about the patch below?
> > 
> > Takashi, thanks for the hack idea. The overhead is just one more loop 
> > which is nothing. I will test it and post details of further problems 
> > (there is a bunch of them :) )
> > 
> 
> Hi,
> 
> The hack works fine, I am finally getting no CPU burning during playback 
> and  MIDI input/output.

Thanks for checking.  The fixed patches are on HG tree now.
Please sync your tree.

> Now the next problem are delays. amidi through ice1724 prints the 
> rawmidi data a fraction of a second later compared to USB midi input. I 
> guess there is not much we could do about it. The format is a bit 
> different which probably does not matter:
> 
> pavel at nahore:~$ amidi -l
> Dir Device    Name
> IO  hw:0,0    Audiotrak Prodigy 192 MIDI
> IO  hw:1,0,0  Keystation Pro 88 MIDI 1
> I   hw:1,0,1  Keystation Pro 88 MIDI 2
> 
> ice1724 midi:
> pavel at nahore:~$ amidi -p hw:0 -d
> 
> 90 2D 5E
>     2D 00
> 90 30 79
>     30 00
> 
> USB midi:
> pavel at nahore:~$ amidi -p hw:1 -d
> 
> 90 2D 4C
> 90 2D 00
> 90 30 5E
> 90 30 00
> 
> However, what makes a huge delay difference is the next step - aseqdump. 
> Here USB still outputs data immediately:
> 
> pavel at nahore:~$ aseqdump -p 20:0
> Waiting for data. Press Ctrl+C to end.
> Source_ Event_________________ Ch _Data__
>   20:0   Note on                 0  41  94
>   20:0   Note on                 0  41   0
>   20:0   Note on                 0  45  80
>   20:0   Note on                 0  45   0
> 
> 
> 
> Whereas through ice1724 midi it takes several seconds for the same notes 
> to appear in aseqdump:
> 
> pavel at nahore:~$ aseqdump -p 16:0
> Waiting for data. Press Ctrl+C to end.
> Source_ Event_________________ Ch _Data__
>   16:0   Active Sensing
>   16:0   Active Sensing
>   16:0   Active Sensing
>   16:0   Active Sensing
>   16:0   Active Sensing
>   16:0   Active Sensing
>   16:0   Active Sensing
>   16:0   Active Sensing
>   16:0   Active Sensing
>   16:0   Active Sensing
>   16:0   Active Sensing
>   16:0   Active Sensing
>   16:0   Note on                 0  43  86
>   16:0   Note on                 0  43   0
>   16:0   Active Sensing
>   16:0   Active Sensing
>   16:0   Active Sensing
>   16:0   Note on                 0  47 100
>   16:0   Note on                 0  47   0
>   16:0   Active Sensing
>   16:0   Active Sensing
>   16:0   Active Sensing
>   16:0   Active Sensing
>   16:0   Active Sensing
>   16:0   Active Sensing
>   16:0   Active Sensing
> 
> Google told me the "Active Sensing" messages are OK. Still, the whole 
> pack of lines appears at once, but with a huge delay.
> 
> When hooking Qsynth to the inputs, notes through USB sound immediately, 
> Notes through ice1724 get delayed by several seconds, but mostly they 
> produce no sound at all. Surprisingly, the few notes which actually make 
> it through sound long (just like the piano sustain pedal). USB notes do 
> not have this effect.

So, now it's a problem of MIDI "input", if I understand correctly?
What we need to check at first is whether the MPU_RX irq is issued at
the correct timing.  If not, check whether MPU watermarks
(MPU_FIFO_WM, CCS0E).  According to the datasheet, the values are 0
for both RX and TX.


Takashi