On 06/27/12 13:07, Clemens Ladisch wrote:
> Bryan Ischo wrote:
>> OK I think I figured out a way:
> This is how mplayer does it.
>
Also - thank you for your response - and one more question:
I did some experimentation and on two systems that I have access to (one
which apparently has better soun
On 06/27/12 13:07, Clemens Ladisch wrote:
>> I don't really understand why snd_pcm_avail() goes greater than the ring
>> buffer size when silence has been played out
> It's the number of frames you have to write to completely fill up
> the buffer.
>
But how can the number of frames needed to compl
Bryan Ischo wrote:
> OK I think I figured out a way:
This is how mplayer does it.
> Immediately after preparing a PCM device, and before doing any writes to
> it, I call snd_pcm_avail() and record that number (in my case, it is
> 16384) as "maxValidAvail".
This is the buffer size.
> Immediately
On 06/26/12 13:24, Bryan Ischo wrote:
>
> I do still get pops, which I don't understand, but they only occur
> after very "large" underruns, where I have allowed a significant
> amount of silence to play, instead of "small" underruns, which happen
> when my thread delivering audio data is very s
On 06/26/12 12:39, Bryan Ischo wrote:
>
> So what I need is a way to tell ALSA to re-sync the application write
> position with the hardware read position without having to reset the
> device.
>
> Before I start digging into the ALSA code to understand this better,
> is there any obvious way to
On 06/26/12 11:03, Bryan Ischo wrote:
> On 06/26/12 10:15, Bryan Ischo wrote:
>>
>> snd_pcm_sw_params_get_boundary(sw_params, &boundary);
>>
>> // Never underrun; allow the sound card to just keep playing whatever
>> is in the ring
>> // buffer, including re-playing old audio if new audio is not a
On 06/26/12 10:15, Bryan Ischo wrote:
>
> snd_pcm_sw_params_get_boundary(sw_params, &boundary);
>
> // Never underrun; allow the sound card to just keep playing whatever
> is in the ring
> // buffer, including re-playing old audio if new audio is not available
> snd_pcm_sw_params_set_stop_threshol
On 06/23/12 05:59, Clemens Ladisch wrote:
> Bryan Ischo wrote:
>> Maybe I don't understand what the boundary is supposed to represent;
>> I thought it was supposed to represent the largest number of audio
>> frames that could be buffered for playback by the driver.
> That would be the buffer size.
Bryan Ischo wrote:
> Maybe I don't understand what the boundary is supposed to represent;
> I thought it was supposed to represent the largest number of audio
> frames that could be buffered for playback by the driver.
That would be the buffer size.
The boundary has no meaning in applications; yo
On 06/22/12 00:54, Clemens Ladisch wrote:
> Bryan Ischo wrote:
>> Hm, I think I may have found the reason that it doesn't work sometimes
>> ... I just printed out the boundary value that I am getting from
>> snd_pcm_sw_params_get_boundary(), and it is 4611686018427387904 (on a 64
>> bit system wher
Bryan Ischo wrote:
> Hm, I think I may have found the reason that it doesn't work sometimes
> ... I just printed out the boundary value that I am getting from
> snd_pcm_sw_params_get_boundary(), and it is 4611686018427387904 (on a 64
> bit system where sizeof(snd_pcm_uframes_t) == 8).
>
> That valu
Bryan Ischo wrote:
> If I change *just* the PCM name that I open; e.g. change this line from
> my capture file:
>
> 000668371: 0: 0: snd_pcm_open default 0 0
>
> to this:
>
> 000668371: 0: 0: snd_pcm_open hw:0,0 0 0
>
> ... and change absolutely nothing else, then I don't get any of the pops
> at a
Bryan Ischo wrote:
> Here is a technique I have tried to reduce the effect of underrun. In
> my application, underrun either means that the process that is
> generating audio can't keep up (it's a game emulator, generating audio
> and video frames at a fixed rate, and some games can't be emulated
Bryan Ischo wrote:
> On one machine that I have access to, that uses an
> Intel ICH10 integrated audio solution, I don't get any pops no matter
> what. But on my home workstation, I do get the pops.
This might be a hardware bug; many HDA controllers don't report
the current position correctly. T
On 06/14/12 23:12, Bryan Ischo wrote:
> On 06/14/12 04:05, Clemens Ladisch wrote:
>> Bryan Ischo wrote:
>>> Hello. I have a program that uses ALSA for audio and I don't understand
>>> why I get lots of pops when starting playback but only on some hardware.
>>>
>>> 000675767: 960: 0: snd_pcm_writei
On 06/14/12 04:05, Clemens Ladisch wrote:
> Bryan Ischo wrote:
>> Hello. I have a program that uses ALSA for audio and I don't understand
>> why I get lots of pops when starting playback but only on some hardware.
>>
>> 000675767: 960: 0: snd_pcm_writei 960 3840
>> 00 00 00 00 c0 f1 c0 f1 c0 f1 c0
On 06/14/12 04:05, Clemens Ladisch wrote:
> Bryan Ischo wrote:
>> Hello. I have a program that uses ALSA for audio and I don't understand
>> why I get lots of pops when starting playback but only on some hardware.
>>
>> 000675767: 960: 0: snd_pcm_writei 960 3840
>> 00 00 00 00 c0 f1 c0 f1 c0 f1 c0
Bryan Ischo wrote:
> Hello. I have a program that uses ALSA for audio and I don't understand
> why I get lots of pops when starting playback but only on some hardware.
>
> 000675767: 960: 0: snd_pcm_writei 960 3840
> 00 00 00 00 c0 f1 c0 f1 c0 f1 c0 f1 c0 f1 c0 f1
> c0 f1 c0 f1 c0 f1 c0 f1 c0 f1 c
On 06/14/12 10:30, Bryan Ischo wrote:
>
> Here is a technique I have tried to reduce the effect of underrun. In
> my application, underrun either means that the process that is
> generating audio can't keep up (it's a game emulator, generating audio
> and video frames at a fixed rate, and some
19 matches
Mail list logo
