Le nonidi 29 pluviôse, an CCXXV, christina zou a écrit : > Here is the result of your two commands:
> 1. time ffmpeg -i temp_arecord.wav temp_ffmpeg.wav > real 0m3.154s > user 0m1.230s > 2. time ffmpeg -i temp_arecord.wav -c copy temp_ffmpeg2.wav > real 0m0.986s > user 0m0.510s (for a 27-seconds input) Well, the issue is obviously not what I suspected, i.e. that the 32->16 bits conversion was too slow for the CPU, since it apparently takes less than 12% of real-time. I suspect the difference might be related to the period time. FFmpeg uses the lowest possible period time to allow low-latency uses, but it makes for heavier CPU consumption. FFmpeg does not have an option to change the period time, but if you can patch and build it yourself, you can hardcode something in libavdevice/alsa.c near line 254. You can also try lowering the period size in arecord and see if it increases CPU consumption. But since arecord's work is simpler than ffmpeg's, it may probably not be enough to observe similar results. Still, it would be interesting. For your next tests, I urge you to make sure no audio conversions happens. You can do that with -c copy. It would also be interesting to see the definition of the mic_sv PCM in the ALSA configuration. It might be a little hard to find it in the spaghetti configuration files. Regards, -- Nicolas George
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".