* daemon:
- do not assume filesystem hierarchy in CMakeLists.txt
- do not replace default CXX compilation flags to avoid breaking
builds with external toolchain (e.g. yocto)
- allow for tests to be enabled/disabled
- allow for cpp-httplib dir to be provided by hand; otherwise search
for it in system locations
- allow for the location of the ravenna alsa lkm to be provided by
hand, otherwise look for it in system locations
Issue is in the mr_alsa_audio_pcm_playback_copy_internal() function of audio_driver.c that transfers the PCM samples from the ALSA buffer to the Ravenna buffer using the get_user() function.
In case of memory access mode the ALSA buffer can be directly accessed by the kernel and the samples must be copied.
mr_alsa_audio_pcm_playback_copy_internal() has been modified to handle the transfer of the ALSA buffer from user space (used with read/write access mode) and from kernel space (used by memory access mode).
The issue is common to all the platform but impacting ARM only.
Additional changes:
- changed type for dma_playback_offset and dma_capture_offset variables to uint32_t instead of atomic_t since the pointer callback mr_alsa_audio_pcm_pointer() is now atomic
- added variables to the mr_alsa_audio_chip scructure to decrease the number of calls to snd_pcm_lib_xxx() functions. These get assigned in the prepare callback mr_alsa_audio_pcm_prepare()
- changed mr_alsa_audio_get_playback_buffer_size_in_frames() to return configured size of Ravenna playback buffer (same as mr_alsa_audio_get_capture_buffer_size_in_frames())
- some rework of the existing patches
This fixes issue #20
Issue is in the mr_alsa_audio_pcm_playback_copy_internal() function of audio_driver.c that transfers the PCM samples from the ALSA buffer to the Ravenna buffer using the get_user() function.
In case of memory access mode the ALSA buffer can be directly accessed by the kernel and the samples must be copied.
mr_alsa_audio_pcm_playback_copy_internal() has been modified can to handle the transfer of the ALSA buffer from user space (used with read/write access mode) and from kernel space (used by memory access mode).
The issue is common to all the platform but impacting ARM only.
Additional changes:
- changed type for dma_playback_offset and dma_capture_offset variables to uint32_t instead of atomic_t since the pointer callback mr_alsa_audio_pcm_pointer() is now atomic
- added variables to the mr_alsa_audio_chip scructure to decrease the number of calls to snd_pcm_lib_xxx() functions. These get assigned in the prepare callback mr_alsa_audio_pcm_prepare()
- changed mr_alsa_audio_get_playback_buffer_size_in_frames() to return configured size of Ravenna playback buffer (same as mr_alsa_audio_get_capture_buffer_size_in_frames())
- some rework of the existing patches
This fixes issue #20wq
PCM samples are transferred by the PCM interrupt routine from the memory of the ALSA playback device to the RAVENNA buffer and from the RAVENNA buffer to the memory of the ALSA capture device.
This patch will enabled the use of the ALSA plugins and it has been testes with the ALSA Dmix plugin.
This patch applies to issues #7 and #15.
These test files contain -10dBFS 1kHz tone on the left channel and 100Hz tone on the right channel. Various formats are available to verify wav header processing. The '.ac3.wav' can be used to verify that the -am824 switch can create compliant AM824/SMPTE 2110-31 stream with Dolby Digital (AC-3) content. This was created with a professional Dolby Digital encoder (not available) and SMPTE 337 wrapping tool (available at Dolby's github repository).
This player is not fully tested due to occasional drops on the output caused CRC errors when used with encoded audio such as Dolby E. However these drops have been observed with aplay when used in memory mapped mode so it is not believed to be an issue with this player. However, final testing is still outstanding
This player is not fully tested due to occasional drops on the output caused CRC errors when used with encoded audio such as Dolby E. However these drops have been observed with aplay when used in memory mapped mode so it is not believed to be an issue with this player. However, final testing is still outstanding
This player is not fully tested due to occasional drops on the output caused CRC errors when used with encoded audio such as Dolby E. However these drops have been observed with aplay when used in memory mapped mode so it is not believed to be an issue with this player. However, final testing is still outstanding
This player is not fully tested due to occasional drops on the output caused CRC errors when used with encoded audio such as Dolby E. However these drops have been observed with aplay when used in memory mapped mode so it is not believed to be an issue with this player. However, final testing is still outstanding
The bug was also preventing the daemon from terminating. It was possible to reproduce the problem using the add_remove_check_mdns_browser_update_all regression test.
