Sound makes erorr after USB module initialized

[meesokim]

Sound makes erorr after USB module initialized

[rsta2]

Other time-critical operations can be a problem when USB is running. You can only increase DMA_BUF_SIZE in pwmsounddevice.cpp (line 41) so that the DMA buffer can hold the full sample and the conversion is done before playing. But this only works with fairly small static samples. Unfortunately I cannot do more about it at the moment.

[meesokim]

USB feature is quite important to take advantage for many application. I'd like to invastigate the root cause. But it is not a simple work as you mentioned. Thank you for your great work!

[rsta2]

Thank you! I think the problem is caused by the implementation of the frame scheduler for periodic interrupt transfers to low speed devices (keyboard, mouse) in dwhciframeschedper.cpp. Because it is important in which micro frame an USB split frame is transmitted one has to wait for that micro frame to come.

This can be done by using interrupts which generates a continous load of 8000 interrupts per second and the response time to this interrupt is very critical. AFAIK Linux on the Raspberry Pi uses this method and implements a special FIQ handler to meet the response time requirements.

The Circle USB HCI driver was intended to be used in a small UNIX like hobby OS with a text console without real-time requirements when it was developed. So I decided to simply (busy) wait for that micro frame which may happen in IRQ context. Because other interrupts will not be handled while waiting there may be an IRQ response time of about one milli-second at worst when an USB keyboard or mouse is connected to the system. That is too long to generate a continous data stream to the PWM FIFO via the platform DMA controller.

Unfortunately it is not easy to change this frame scheduling method and currently I cannot do that. The problem should not arise on USB Ethernet or mass-storage device only systems. In a desktop environment with keyboard and mouse PWM sound could be implemented using two chained DMA buffers alternating and generating an interrupt when one buffer was transfered so that there is enough time to fill the other. Unfortunately this is currently not supported by the CDMAChannel class.

[rsta2]

To clarify this: Circle is not a real-time OS and is not intended to be one. That means different simultaneous operations may interfere in respect of its timing behaviour. The provided samples are tested to work but if you try different combinations of hardware support classes this has to be tested by yourself. I have added a similar notice in the main README file. So this issue will not be fixed.