ralphy wrote: 
> The 'EDO applet for the touch'
> (https://github.com/ralph-irving/EnhancedDigitalOutput) might be a good
> starting point for an applet to change the buffer period count and time
> for the radio.
> 
> It doesn't allow you to enter values but rather supplies a list of
> options to choose from and the kernel updater section would need to be
> removed.

Thanks for the pointer. I'll follow that up.

Both my radios are rev 5, running 7.7.3 r16676.


Code:
--------------------
    # cat /etc/squeezeos.version
  7.7.3 r16676
  r...@ec2mbubld01.idc.logitech.com Fri Feb 14 09:25:26 PST 2014
  Base build revision:  bad080aecfec8226a4c1699b29d32cbba4ba396b
  
  # egrep '(^Hardware|^Revision)' /proc/cpuinfo
  Hardware      : Logitech MX25 Baby Board
  Revision      : 0005
--------------------


My money's still on there being a software issue within ALSA and/or the
Crossover component. For the reasons I've already posted. I have found a
significant correlation with the playing out of effects, although not
exclusively so, and slartibartfast seems to have a somewhat effect free
Radio, but still gets the drop-outs.

But I have no experience of ALSA programming, perhaps there is something
adrift with the way jive_alsa starts/re-starts a stream, I couldn't
possibly tell. 

It would be intriguing if a hardware/firmware difference between
revisions 0005 and 0007 were also in play. I couldn't see anything
obvious in the SqueezeOS repository, but that doesn't mean much.

The occurrences are sufficiently infrequent in normal usage that it is
almost impossible to gather any reliable statistics. And different
people will be using their Radios in different ways, with different
stream providers, so the CPU load patterns will differ. Confirmation
bias becomes an issue when trying to make an accurate diagnosis.

For reference, I have seen one, or other, or both, of the following ALSA
error messages when bass drop-out occurs. But usually bass drop-out does
not happen, despite seeing them.

Code:
--------------------
    
  Jan 27 16:26:45 squeezeplay: audio_thread_execute:862 underrun!!! (at least 
-2359940.244 ms long)
  Jan 27 16:34:56 squeezeplay: audio_thread_execute:1025 xrun 
(snd_pcm_mmap_commit) err=-32
  And sometimes this kernel message:
  Jan 27 16:34:56 kernel: [ 3387.946675] ssi1_irq SISR 120 SIER 180100 
fifo_errs=1
  
--------------------

The first is in consequence of ALSA reporting 'SND_PCM_STATE_XRUN'. In
either case, jive_alsa then calls  'snd_pcm_recover', which seems to
succeed.
The kernel message is, I think, reporting a DMA under-run at the i.MX25
hardware level - ran out of samples to transfer over the serial lines to
the sound chip.


------------------------------------------------------------------------
mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299
View this thread: http://forums.slimdevices.com/showthread.php?t=104141

_______________________________________________
Radio mailing list
Radio@lists.slimdevices.com
http://lists.slimdevices.com/mailman/listinfo/radio

Reply via email to