I will try it. I just changed 44100 to 48000 in my ALSA code and now snd_pcm_hw_params is failing with "Invalid argument" so maybe I will have to switch over to OMX for this test.dom wrote:What's 48kHz like?
The board runs off a 19.2MHz oscillator. 48kHz is a integer divisor of this. 44.1KHz is not.
I would expect the PLLs that produce the audio clock will work better with an integer divisor.
It doesn't need to be perfect. The video/audio will usually only be playing for less than 1 minute which means as long as the clock is reasonably close to the target, it will be good enough with some buffering. Unfortunately, 44275 seems to be too different from 44100 to stay in sync for that long.However your design won't work. Even if the clocks are 100 or 1000 times more accurate, they will still drift too far apart *eventually*.
You need a feedback path for a project like this.
I currently am using openmax for jpeg decoding (which each jpeg represents one NTSC field), and gles2 for the actual rendering (it is working great, BTW). So I can still use ALSA if it makes sense to do so; I have both "working" ALSA and OMX audio code in my project and they both seem to have the same problem (which I suppose isn't surprising).I don't really understand if you are planning on using openMAX for the video playback? If so, you won't be using ALSA.
The resampler is used for HDMI audio, where the sink typically only supports a few discrete sample rates.MattOwnby wrote: I will try it. I just changed 44100 to 48000 in my ALSA code and now snd_pcm_hw_params is failing with "Invalid argument" so maybe I will have to switch over to OMX for this test.I don't see why that should fail. ALSA driver reports it support 8000-48000 as sampling rates.
Do you have a asound.conf file?MattOwnby wrote:Could you give me some hints on how to find this resampler? Is it part of "audio_mixer" ? If 48khz mode is a lot closer, I could resample my source 44.1khz data to 48khz before playing it.
Could this arbitrary variation of the PWM clock be the cause for the inaccuracies? Or is it the hardware itself?dom wrote: As the analogue audio can vary the PWM clock arbitrarily, that resampling isn't required.
Ok, I modified hello_audio and here is what I got after letting it run for a while:/opt/vc/src/hello_pi/hello_audio does output 48kHz over openMAX, so you could try timing that to see if the drift is better.
Code: Select all
Total elapsed time: 4126.477000 Total frames processed: 198854656 Effective audio frequency: 48189.934416
Users browsing this forum: No registered users and 8 guests