ALSA on Raspbian


165 posts   Page 3 of 7   1, 2, 3, 4, 5, 6, 7
by kadamski » Fri Jul 20, 2012 8:25 pm
@Dom
I suspect that it is indeed VC problem. When playing audio with low sample rate, it hangs on bcm2835_audio_write -> vchi_bulk_queue_transmit ->ioctl(VCHIQ_IOC_QUEUE_BULK_TRANSMIT) ->vchiq_ioctl -> vchiq_bulk_transfer -> vcos_event_wait -> down_interruptible()

Now, if I understand correctly, since VCHI_FLAGS_BLOCK_UNTIL_DATA_READ flag is used on vchi_bulk_queue_transmit, it blocks on vcos_event_wait, using semaphore. And this semaphore is upped from notify_bulks() using vcos_event_signal(), when VC confirms data read. Is that correct? So it is not really ALSA related and it's VC fault that it don't confirm receiving data?

I suspect that the information about supported sample rates (linear between 8000-48000) in bcm2835-pcm.c is correct and it just should support those low sample rates?
Posts: 187
Joined: Fri Jun 08, 2012 10:56 pm
by gritz » Fri Jul 20, 2012 10:27 pm
I wish I knew more about it too (and that I could remember what little of the ALSA-related whatnot I took in years ago when trying to make sense of audio on Linux).

Obviously the hardware output is limited to 2 channel, 11bit @ 48k so I guess that (as you've bypassed the plugin) ALSA is just checking that the audio is within the allowed rates and passing the pcm to the 2835 which does the resampling / bit depth adjustment? If (say) resampling before passing to the hardware (or the pipe to the hardware) doesn't work either then it might suggest an "upstream" problem. In any case issues with a lower bitrate stream might infer a buffer underrun because of a timing problem? Don't know - this isn't like discrete hardware with a fifo, converter with defined params and whatnot.

Sorry about lowering the s/n ratio of the thread - I'm just thinking aloud.
Posts: 449
Joined: Sat Jan 28, 2012 2:33 am
by wildehobbs » Sat Jul 21, 2012 10:20 am
I am a linux newbie so apologies for any silly questions...

I am trying to get an amateur radio application wspr to run on the raspberry pi, and have it compiled with the hardware libraries (I think!), but when opened it gives the following messages:


ALSA lib confmisc.c:1286:(snd_func_refer) Unable to find definition 'cards.BRCM bcm2835 AL.pcm.front.0:CARD=0'
ALSA lib conf.c:4241:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:4720:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2217:(snd_pcm_open_noupdate) Unknown PCM front
ALSA lib pcm.c:2217:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.rear
ALSA lib pcm.c:2217:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.center_lfe
ALSA lib pcm.c:2217:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.side
ALSA lib confmisc.c:1286:(snd_func_refer) Unable to find definition 'cards.BRCM bcm2835 AL.pcm.surround40.0:CARD=0'
ALSA lib conf.c:4241:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:4720:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2217:(snd_pcm_open_noupdate) Unknown PCM surround40
ALSA lib confmisc.c:1286:(snd_func_refer) Unable to find definition 'cards.BRCM bcm2835 AL.pcm.surround51.0:CARD=0'
ALSA lib conf.c:4241:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:4720:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2217:(snd_pcm_open_noupdate) Unknown PCM surround41
ALSA lib confmisc.c:1286:(snd_func_refer) Unable to find definition 'cards.BRCM bcm2835 AL.pcm.surround51.0:CARD=0'
ALSA lib conf.c:4241:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:4720:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2217:(snd_pcm_open_noupdate) Unknown PCM surround50
ALSA lib confmisc.c:1286:(snd_func_refer) Unable to find definition 'cards.BRCM bcm2835 AL.pcm.surround51.0:CARD=0'
ALSA lib conf.c:4241:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:4720:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2217:(snd_pcm_open_noupdate) Unknown PCM surround51
ALSA lib confmisc.c:1286:(snd_func_refer) Unable to find definition 'cards.BRCM bcm2835 AL.pcm.surround71.0:CARD=0'
ALSA lib conf.c:4241:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:4720:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2217:(snd_pcm_open_noupdate) Unknown PCM surround71
ALSA lib confmisc.c:1286:(snd_func_refer) Unable to find definition 'cards.BRCM bcm2835 AL.pcm.iec958.0:CARD=0,AES0=4,AES1=130,AES2=0,AES3=2'
ALSA lib conf.c:4241:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:4720:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2217:(snd_pcm_open_noupdate) Unknown PCM iec958
ALSA lib confmisc.c:1286:(snd_func_refer) Unable to find definition 'cards.BRCM bcm2835 AL.pcm.iec958.0:CARD=0,AES0=4,AES1=130,AES2=0,AES3=2'
ALSA lib conf.c:4241:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:4720:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2217:(snd_pcm_open_noupdate) Unknown PCM spdif
ALSA lib confmisc.c:1286:(snd_func_refer) Unable to find definition 'cards.BRCM bcm2835 AL.pcm.iec958.0:CARD=0,AES0=4,AES1=130,AES2=0,AES3=2'
ALSA lib conf.c:4241:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:4720:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2217:(snd_pcm_open_noupdate) Unknown PCM spdif
ALSA lib pcm.c:2217:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.hdmi
ALSA lib pcm.c:2217:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.hdmi
ALSA lib pcm.c:2217:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.modem
ALSA lib pcm.c:2217:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.modem
ALSA lib pcm.c:2217:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.phoneline
ALSA lib pcm.c:2217:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.phoneline
ALSA lib pcm_dmix.c:957:(snd_pcm_dmix_open) The dmix plugin supports only playback stream
ALSA lib pcm_direct.c:877:(snd1_pcm_direct_initialize_slave) slave plugin does not support mmap interleaved or mmap noninterleaved access
ALSA lib pcm_dmix.c:1030:(snd_pcm_dmix_open) unable to initialize slave


I am using a USB sound card, which is found and appears in the list of devices within the program.

When run the application starts but does not seem to be able to receive the audio streams from the USB line in.

Any ideas on how to solve this?

Dave
Posts: 2
Joined: Sat Jul 21, 2012 10:11 am
by dom » Sat Jul 21, 2012 12:53 pm
kadamski wrote:@Dom
I suspect that it is indeed VC problem. When playing audio with low sample rate, it hangs on bcm2835_audio_write -> vchi_bulk_queue_transmit ->ioctl(VCHIQ_IOC_QUEUE_BULK_TRANSMIT) ->vchiq_ioctl -> vchiq_bulk_transfer -> vcos_event_wait -> down_interruptible()

Now, if I understand correctly, since VCHI_FLAGS_BLOCK_UNTIL_DATA_READ flag is used on vchi_bulk_queue_transmit, it blocks on vcos_event_wait, using semaphore. And this semaphore is upped from notify_bulks() using vcos_event_signal(), when VC confirms data read. Is that correct? So it is not really ALSA related and it's VC fault that it don't confirm receiving data?

I suspect that the information about supported sample rates (linear between 8000-48000) in bcm2835-pcm.c is correct and it just should support those low sample rates?


VC handles arbitrary samplerates. For analogue audio, it just sets the PWM clock to a multiple of the samplerate. For HDMI it software resamples (by GPU) to the nearest supported samplerate.
Are you seeing the problem on HDMI or analogue?

Now, what I think is happening is that in general ALSA sends a certain amount of sample data which VC adds to its audio output buffer. Currently this is 32K in size (I can make this bigger, but it is a compile time change).
Once ALSA has preloaded this buffer it sends a start signal, and we start playing it, sending messages describing how much has been consumed and adding new data to buffer.

However if ALSA tries to overfill the audio buffer, we will block until there is space. If this happens before the start message, the space will never come so we will lock up.
I guess for safety I should discard data at this point to avoid the lockup, but that's still an undesirable situation as we have lost data.

I've been assuming ALSA will never send more that it's buffer size, which I believe is 31K. That's probably true.
However VC's audio buffer is after processing, which includes expanding 8->16bit, and samplerate conversion (I think that will only happen with HDMI, not analogue).

So problem is that resampling from low samplerate to high samplerate (because HDMI only supports perhaps 44.1kHz) produces more output data than input and we end up with >32K of data and we lock up.

A few solutions are possible:
Discard too much audio data without blocking before starting playback. This may be a problem even after starting if ALSA tries to maintain "fullness" level that doesn't fit. (*)
Use the "plug" device to force only 48kHz / 16bit data to be delivered to ALSA driver. Resampling by plug may be costly
Increase the VC audio buffer size by a factor of 12 to handle 8kHz->48kHz resample, plus 8bit->16bit. That will cost 352K in memory.
Reduce ALSA driver buffer size by a factor of 12. Will make underruns more likely, and some apps may not be happy.

(*) is worth doing anyway as dropped samples are preferable to hangs, but we should try to ensure the condition isn't hit.
A combination of the above may be useful. E.g. use plug for 8bit->16bit which is cheap. Perhaps also use it for resampling from <16kHz which is relatively cheap, and proably only used by low end games.
Then buffer size only needs increasing by a factor of 3.

To use plug, we need to understand exactly how it's supposed to be enabled. We have found here that adding this file (/etc/asound.conf or alternately ~/.asoundrc)

Code: Select all
pcm.!default {
                type plug
                slave {
                                pcm “plughw:0,0”
                                format S16_LE
                }
}


seems to allow other formats (e.g. 24bit) and also avoids the 10 second hang you sometimes get when shutting down ALSA.
Is that a sensible config file to include as default on official images?
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 4011
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge
by kadamski » Sat Jul 21, 2012 2:42 pm
dom wrote:VC handles arbitrary samplerates. For analogue audio, it just sets the PWM clock to a multiple of the samplerate. For HDMI it software resamples (by GPU) to the nearest supported samplerate.
Are you seeing the problem on HDMI or analogue?

I only have DVI monitor so I'm using analogue output. I did switch the output using amixer cset and although I don't hear anything so I don't know if it started playback or not, it seems to be broken too with low sample rates. It doesn't lookup, however it outputs:
Code: Select all
aplay: pcm_write:1710: write error: Input/output error

Switching back to analogue and I have my sound back. So it only lockup in analogue.

dom wrote:Now, what I think is happening is that in general ALSA sends a certain amount of sample data which VC adds to its audio output buffer. Currently this is 32K in size (I can make this bigger, but it is a compile time change).
Once ALSA has preloaded this buffer it sends a start signal, and we start playing it, sending messages describing how much has been consumed and adding new data to buffer.

However if ALSA tries to overfill the audio buffer, we will block until there is space. If this happens before the start message, the space will never come so we will lock up.
I guess for safety I should discard data at this point to avoid the lockup, but that's still an undesirable situation as we have lost data.

I've been assuming ALSA will never send more that it's buffer size, which I believe is 31K. That's probably true.
However VC's audio buffer is after processing, which includes expanding 8->16bit, and samplerate conversion (I think that will only happen with HDMI, not analogue).

So problem is that resampling from low samplerate to high samplerate (because HDMI only supports perhaps 44.1kHz) produces more output data than input and we end up with >32K of data and we lock up.

playing 2 channels at samplerate 11500 in S16_LE, I got lock up at 17232 bytes send. I mean, after 11488 bytes transfered it's still ok but when trying to send another 5744 bytes, it locks up. On analogue. So if your theory is true, if would have to be extended 2 times in VC. You can see that from my dmesg which has some debug messages added - http://pastebin.com/Kn6nU4cD It's the first play of any sound after reboot.

Here's another one with the maximal samplerate that triggers (21360 at 2 channels) the bug: http://pastebin.com/GAeM9HyF It does lock up when 31k is goint to be exceeded and we can see that ALSA triggers the start at the same time.

But why am I albe to send ~32k without problems at higher sample rate but at lower one, I can only send ~16k?

dom wrote:A few solutions are possible:
Discard too much audio data without blocking before starting playback. This may be a problem even after starting if ALSA tries to maintain "fullness" level that doesn't fit. (*)
Use the "plug" device to force only 48kHz / 16bit data to be delivered to ALSA driver. Resampling by plug may be costly
Increase the VC audio buffer size by a factor of 12 to handle 8kHz->48kHz resample, plus 8bit->16bit. That will cost 352K in memory.
Reduce ALSA driver buffer size by a factor of 12. Will make underruns more likely, and some apps may not be happy.

(*) is worth doing anyway as dropped samples are preferable to hangs, but we should try to ensure the condition isn't hit.
A combination of the above may be useful. E.g. use plug for 8bit->16bit which is cheap. Perhaps also use it for resampling from <16kHz which is relatively cheap, and proably only used by low end games.
Then buffer size only needs increasing by a factor of 3.


This 352K of memory is a VC or ARM mermory? I belive it's not that much anyway. And yes, the 1st one is worth doing anyway in a long run.

dom wrote:To use plug, we need to understand exactly how it's supposed to be enabled. We have found here that adding this file (/etc/asound.conf or alternately ~/.asoundrc)

Code: Select all
pcm.!default {
                type plug
                slave {
                                pcm “plughw:0,0”
                                format S16_LE
                }
}


seems to allow other formats (e.g. 24bit) and also avoids the 10 second hang you sometimes get when shutting down ALSA.
Is that a sensible config file to include as default on official images?


It's almost the same as the config I posted here using lfloat plugin:
Code: Select all
pcm.float {
  type lfloat
  slave {
    pcm "plughw:0,0"
    format S16_LE
  }
}

I belive in essense they both do the same but using lfloat is just more explicit at what we need. I don't know anything about 10 seconds bug at shutting down ALSA but I do belive that we should have something like this in default ALSA config at least untill we get MMAP to work. Or maybe we should use mmap_emul variant that will also allow plughw to work on >2 channels PCM (but the downside is bigger latency).


BTW you didn't answer my question about how vchi_bulk_queue_transmit in VCHI_FLAGS_BLOCK_UNTIL_DATA_READ mode works and I would appriciate if you did. Are my assumtions right?
Posts: 187
Joined: Fri Jun 08, 2012 10:56 pm
by kadamski » Sat Jul 21, 2012 2:45 pm
@wildehobbs
What distribution are you using? What is the program you are running? What is the output of "aplay -l" and "aplay -L" ? Do you have /etc/asound.conf or ~/.asoundrc files? If so, what is it's content?
Posts: 187
Joined: Fri Jun 08, 2012 10:56 pm
by dom » Sat Jul 21, 2012 3:06 pm
kadamski wrote:Now, if I understand correctly, since VCHI_FLAGS_BLOCK_UNTIL_DATA_READ flag is used on vchi_bulk_queue_transmit, it blocks on vcos_event_wait, using semaphore. And this semaphore is upped from notify_bulks() using vcos_event_signal(), when VC confirms data read. Is that correct? So it is not really ALSA related and it's VC fault that it don't confirm receiving data?


The ARM and VC have (conceptually) distinct memory spaces, so VCHIQ messages will always involve a copy operation from ARM memory to VC memory (or vice versa). This copy is done though DMA so is pretty efficient.
Non-bulk vchiq messages are limited to <4K and get copied to a pool of control blocks on the ARM side, so generally don't block, but have an additional copy.
Bulk vchiq messages can be larger and just have the DMA copy. The copy only occurs when VC is ready, so they are more likely to block.

VCHI_FLAGS_BLOCK_UNTIL_QUEUED just means the buffer (pointer) has been added to the VCHIQ transmit queue, but hasn't necessarily been copied yet, so the buffer cannot be reused.
VCHI_FLAGS_BLOCK_UNTIL_DATA_READ means the data has been finished with on ARM side (i.e. the DMA copy has occurred) and the buffer is free to be resused. It's not guaranteed that VC has actually processed it.

So, yes, If any vchiq transmit function blocks for more than milliseconds, it suggests VC is not behaving as it should.
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 4011
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge
by kadamski » Sat Jul 21, 2012 3:10 pm
But am I right about the implementation of the blocking? It uses semaphore that us upped after DMA copy has occurred? Where in code does this up happen? Is it from notify_bulks? And what calls notify_bulks? Thank you for clarifications.
Posts: 187
Joined: Fri Jun 08, 2012 10:56 pm
by dom » Sat Jul 21, 2012 3:22 pm
kadamski wrote:playing 2 channels at samplerate 11500 in S16_LE, I got lock up at 17232 bytes send. I mean, after 11488 bytes transfered it's still ok but when trying to send another 5744 bytes, it locks up. On analogue. So if your theory is true, if would have to be extended 2 times in VC. You can see that from my dmesg which has some debug messages added - http://pastebin.com/Kn6nU4cD It's the first play of any sound after reboot.

Actually the output audio buffer is 32-bits per sample, and stereo (whatever the input size). So >16K of 16-bit stereo is going to lockup.

kadamski wrote:But why am I albe to send ~32k without problems at higher sample rate but at lower one, I can only send ~16k?

So, 32K is being sent before the start command? I think that should lockup. Once the start command has been sent, there's no lockup but the bulk queue transmit might stall until samples are played out.

kadamski wrote:This 352K of memory is a VC or ARM mermory? I belive it's not that much anyway. And yes, the 1st one is worth doing anyway in a long run.

VC memory. Yes, if a larger buffer makes the ALSA driver perfect, I think it is worth the memory cost. (Although it might be 704K now I know it's 32bit)

kadamski wrote:I don't know anything about 10 seconds bug at shutting down ALSA but I do belive that we should have something like this in default ALSA config at least untill we get MMAP to work. Or maybe we should use mmap_emul variant that will also allow plughw to work on >2 channels PCM (but the downside is bigger latency).


I think this demonstrates the 10 second pause when shutting down ALSA (the python games on new image also do).
Code: Select all
SDL_AUDIODRIVER=alsa python -c "import pygame; from time import time; pygame.init(); print('did init'); t1=time();pygame.mixer.quit();print time()-t1"

Takes 10 seconds without the "plug" config file. It's quick with it.
Worth experimenting with mmap_emul to see if it helps.
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 4011
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge
by KenT » Sat Jul 21, 2012 3:37 pm
Don't know if it helps but asb has done a little more investigation of the delay in shutting down pygame.

https://github.com/asb/spindle/issues/85

Its quite an annoying bug because it happens even of the sound is not used in the program.
Pi Presents - A toolkit to produce multi-media interactive displays for museums, visitor centres, and more
Download from http://pipresents.wordpress.com
Posts: 583
Joined: Tue Jan 24, 2012 9:30 am
Location: Hertfordshire, UK
by Efcis » Sat Jul 21, 2012 3:46 pm
@Dom @kadamski I don't know if it can help, but I'm constantly experiencing underrun errors (sent by aplay I guess) every 5 seconds or so, when sendind thru stdin 16 bit audio samples (mono) sampled at 44100 or 48000. I'm trying to use a DVB-T stick with the raspi. Check my project thread for more details.
Posts: 25
Joined: Thu Sep 01, 2011 8:26 pm
by kadamski » Sat Jul 21, 2012 3:49 pm
dom wrote:Actually the output audio buffer is 32-bits per sample, and stereo (whatever the input size). So >16K of 16-bit stereo is going to lockup.

So, 32K is being sent before the start command? I think that should lockup. Once the start command has been sent, there's no lockup but the bulk queue transmit might stall until samples are played out.


This doesn't explain to me why it lock up at different transfersize for different sample rates. Even more, I don't understand why it does not lock up with higher sample rates. But maybe I'm missing something?

dom wrote:VC memory. Yes, if a larger buffer makes the ALSA driver perfect, I think it is worth the memory cost. (Although it might be 704K now I know it's 32bit)

BTW, why isn't ALSA driver supporting some 32bit PCM if that's native format for the audio device?

dom wrote:
Code: Select all
SDL_AUDIODRIVER=alsa python -c "import pygame; from time import time; pygame.init(); print('did init'); t1=time();pygame.mixer.quit();print time()-t1"

Takes 10 seconds without the "plug" config file. It's quick with it.
Worth experimenting with mmap_emul to see if it helps.


That's strange. I'm getting 10s no matter what I set in asoundrc - plugw -> plughw, mmap_emul -> plughw or lfloat -> plughw. So I can't get this fixed even with your proposed config. Are you sure it's the config that solves this in yuor case?
Posts: 187
Joined: Fri Jun 08, 2012 10:56 pm
by dom » Sat Jul 21, 2012 3:54 pm
KenT wrote:Its quite an annoying bug because it happens even of the sound is not used in the program.


Can you try with one of the versions of:
~/.asoundrc
suggested by me or kadamski. I think that fixes it.
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 4011
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge
by dom » Sat Jul 21, 2012 3:56 pm
kadamski wrote:But am I right about the implementation of the blocking? It uses semaphore that us upped after DMA copy has occurred? Where in code does this up happen? Is it from notify_bulks? And what calls notify_bulks? Thank you for clarifications.

I'm afraid that code is not written by me, so I can't give you an instant answer. I can probably find out Monday from the author.
(although at the moment I think vchiq is behaving correctly, it's just the audio server task on GPU that blocks when its buffer is full).
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 4011
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge
by kadamski » Sat Jul 21, 2012 4:09 pm
For now, I was only able to find out that the 10s wait is on a SNDRV_PCM_IOCTL_DRAIN ioctl.
Posts: 187
Joined: Fri Jun 08, 2012 10:56 pm
by dom » Sat Jul 21, 2012 4:23 pm
kadamski wrote:For now, I was only able to find out that the 10s wait is on a SNDRV_PCM_IOCTL_DRAIN ioctl.


I think all the ioctl get passed back to snd_pcm_lib_ioctl. I assume either pcm core deals with it, or it comes back as a trigger.
I'm not doing anything special for draining which is possibly an omission. I'd be interested to know what I should do after the SNDRV_PCM_IOCTL_DRAIN ioctl.
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 4011
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge
by kadamski » Sat Jul 21, 2012 4:32 pm
That's true. I'm trying to figure that out right now. I found out that 10 s is a timeout for draining to finish (using schedule_timeout_interruptible). I'll be back with more details about this problem. I'm very curious why asoundrc trick fixes that for you but not for me, however.

BTW, there are a lot of plots in this thread right now (plughw/MMAP, low sample rates, drain problem), maybe you could split this? At least getting moving drain problem to another thread should be easy. Or maybe should I create issues on github and summarize all the the informations so far there?
Posts: 187
Joined: Fri Jun 08, 2012 10:56 pm
by asb » Sat Jul 21, 2012 4:34 pm
kadamski wrote:BTW, there are a lot of plots in this thread right now (plughw/MMAP, low sample rates, drain problem), maybe you could split this? At least getting moving drain problem to another thread should be easy. Or maybe should I create issues on github and summarize all the the informations so far there?


I think making separate issues with an intelligent summary would be incredibly helpful.
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 794
Joined: Fri Sep 16, 2011 7:16 pm
by dom » Sat Jul 21, 2012 4:47 pm
Agreed. There are a few unrelated bugs going on here. A separate github issue for each is probably useful.
(and maybe a spindle one for asb about including a suitable /etc/asound.conf to get the plug format conversion working).

I've stopped it blocking when VC audio buffer is full before we start playing, and I've increased audio output buffer size to 256K.
I've also stopped hdmi from discarding samples written before the start (causing first second of audio to be lost on HDMI - analogue already had this fix).
https://dl.dropbox.com/u/3669512/temp/start_alsa.elf

It does fix the 11025 samplerate hang for me.
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 4011
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge
by kadamski » Sat Jul 21, 2012 5:07 pm
Tested, can't reproduce the problem anymore. How about you @Efcis ? This should probably close the https://github.com/raspberrypi/firmware/issues/62
Posts: 187
Joined: Fri Jun 08, 2012 10:56 pm
by Efcis » Sat Jul 21, 2012 5:23 pm
Not very familiar with these files, actually. I replaced start.elf in the /boot directory by the proposed start_alsa.elf (after renaming), but further reboots hang. Do I miss something ?
Posts: 25
Joined: Thu Sep 01, 2011 8:26 pm
by kadamski » Sat Jul 21, 2012 5:31 pm
Do you see colorful test screen or only black screen? Is green led flashing? How many green led flashes do you have? Which OS image are you using?
Posts: 187
Joined: Fri Jun 08, 2012 10:56 pm
by ferrymanr » Sat Jul 21, 2012 7:17 pm
wildehobbs wrote:I am a linux newbie so apologies for any silly questions...

I am trying to get an amateur radio application wspr to run on the raspberry pi, and have it compiled with the hardware libraries (I think!), but when opened it gives the following messages:


ALSA lib confmisc.c:1286:(snd_func_refer) Unable to find definition 'cards.BRCM bcm2835 AL.pcm.front.0:CARD=0'
ALSA lib conf.c:4241:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
etc.

I am using a USB sound card, which is found and appears in the list of devices within the program.

When run the application starts but does not seem to be able to receive the audio streams from the USB line in.

Any ideas on how to solve this?

Congratulations on getting this far. I finally got ./configure to run without error and ran make with lots of warnings but no error. Basically following G3WKWs instructions (link from wsprnet.org) although he uses an earlier wheezy-armhf version than I am.
Dick G4BBH
Posts: 61
Joined: Fri Mar 16, 2012 11:09 pm
by KenT » Sat Jul 21, 2012 7:30 pm
dom wrote:
Can you try with one of the versions of:
~/.asoundrc
suggested by me or kadamski. I think that fixes it.


Tried without success, here is what I did:

On the pi copy and paste from the website into leafpad. Saved and tried in both the suggested directories. Got this error on both times I tried to run a python file having pygame.

Code: Select all
ALSA lib conf.c:1686:(snd_config_load1) _toplevel_:7:1:Unexpected char
ALSA lib conf.c:3406:(config_file_open) /etc/asound.conf may be old or corrupted: consider to remove or fix it
*** glibc detected *** python: munmap_chunk(): invalid pointer: 0x403e2ff8 ***


file used was

Code: Select all
pcm.!default {
                type plug
                slave {
                                pcm “plughw:0,0”
                                format S16_LE
                }
}


Edit: Should of said that I didn't log out or reboot after adding the file.
Pi Presents - A toolkit to produce multi-media interactive displays for museums, visitor centres, and more
Download from http://pipresents.wordpress.com
Posts: 583
Joined: Tue Jan 24, 2012 9:30 am
Location: Hertfordshire, UK
by kadamski » Sat Jul 21, 2012 7:33 pm
There is probably problem with " characters. Replace them typing them manually.
Posts: 187
Joined: Fri Jun 08, 2012 10:56 pm