omxplayer plays a little fast.

[di512]

And I see no way to adjust play speed, especially for live stream.

[6by9]

What are you playing?
It should be playing based on the timestamps in the stream, so unless the system clock is somehow running fast, playing fast implies those timestamps are wrong.

[di512]

Local mp3 and mp4 files, live stream. No matter what I play. Sound will be a little faster in case when omxplayer use external (USB) sound card.

No such problem in case with mpv.

[6by9]

Still too little information really.
Your sound card will be producing an internal clock, and the Pi will be supplying audio to it to be consumed. If that clock is faster than intended then the pitch will increase and it'll play faster.

The most likely thing I can think of is that the sound card is actually running at 48kHz whilst the Pi is being told it is at 44.1kHz (both of those are audio industry standard sample rates). Time how long it takes to play back a file that you know the length of. If it is x0.919 of the actual time (44.1/48), then your card is reporting an incorrect clock. Just don't ask me how to fix it as I don't know.

Does it happen if you use HDMI audio or the on board audio of the Pi?

[di512]

This does not happen whel I play audio to HDMI; when I play audio with mpv.

Previously this sound card was tested on my laptop. There was nothing wrong.

Code: Select all

pcm.dmix2_true {
    type dmix
    ipc_key 674249
    ipc_key_add_uid false 
    ipc_perm 0666
    slave {
        pcm "hw:1,0"
        rate 48000
        format "S16_LE"
        #
        period_time 0
        period_size 1024
        buffer_time 0
        buffer_size 8192
    }
    bindings {
        0 0
        1 1
    }
}

[di512]

One song played with different players trough the same device.

Code: Select all

Audio
Format                                   : MPEG Audio
Format version                           : Version 1
Format profile                           : Layer 3
Mode                                     : Joint stereo
Duration                                 : 4mn 4s
Bit rate mode                            : Constant
Bit rate                                 : 320 Kbps
Channel(s)                               : 2 channels
Sampling rate                            : 44.1 KHz
Compression mode                         : Lossy
Stream size                              : 9.31 MiB (98%)

raspbian. usb. omxplayer.

Code: Select all

real    3m45.085s
user    0m26.970s
sys     0m5.230s

raspbian. usb. omxplayer. (again)

Code: Select all

real    3m45.100s
user    0m26.670s
sys     0m3.990s

raspbian. usb. mpv.

Code: Select all

real    4m4.837s
user    0m25.790s
sys     0m4.710s

raspbian. usb. mpg123.

Code: Select all

real    4m4.333s
user    0m11.190s
sys     0m1.240s

raspbian. usb. mplayer.

Code: Select all

real    4m4.928s
user    0m18.280s
sys     0m0.630s

These representative results make me think that omxplayer have a bug.

[jehutting]

Have you tried it with the rate (in .asoundrc) set to 44100? What are the time values with this rate?

[di512]

real 3m44.963s

[jehutting]

Tried several mp3 (and video) files and omxplayer -with output to an USB audio dongle- plays them all on time .

Have you tried a file with audio rate 48000? (I couldn't find an MP3 file in my collection with such a rate, but found a movie with an audio stream with rate 48000, and that one played fine too).

Have you tried another USB audio dongle?
I know the other players play fine, and yes there is something strange going on with omxplayer, but omxplayer calls somewhere in the line 'snd_pcm_hw_params_set_rate_near' to set the required rate. I do not know how these 'other' players do it, but I assume they call something similar. But still I want to exclude it is the dongle causing omxplayer to have trouble with it.

[di512]

I see no difference in case with 48000 rate. You can make such files with lame encoder.
I have no another USB dongle.

[di512]

"no difference" mean no difference between mpv and omxplayer. So, in this case omxplayer works as expected.

[di512]

WebM format not supported. Poor player.

[E3V3A]

I have the same problem.

I use an external USB soundcard.
All other programs are able to use it with no problem, except omxplayer.

* For some reason, omxplayer doesn't respect the mp3 sample rate.

Code: Select all

$ omxplayer -i file1.mp3
...
  Duration: 00:00:03.92, start: 0.000000, bitrate: 35 kb/s
    Stream #0:0: Audio: mp3, 11025 Hz, mono, s16p, 32 kb/s

$ omxplayer -i file2.mp3
...
  Duration: 00:00:05.34, start: 0.000000, bitrate: 58 kb/s
    Stream #0:0: Audio: mp3, 22050 Hz, stereo, s16p, 56 kb/s

Running them produces 4x and 2x the rate.

Code: Select all

$ omxplayer -o alsa file1.mp3
Audio codec mp3 channels 1 samplerate 11025 bitspersample 16
Subtitle count: 0, state: off, index: 1, delay: 0

$ omxplayer -o alsa file2.mp3
Audio codec mp3 channels 2 samplerate 22050 bitspersample 16
Subtitle count: 0, state: off, index: 1, delay: 0

I've tried every option available, to no use.

Also, I read that omxplayer doesn't use ALSA subsystem, so what does it use?
Where are the config/setting files for omxplayer?

[E3V3A]

Apparently omxplayer ignores the embedded sample rate and continue to use 44100 Hz, thus speeding through the file 2 respectively 4 times as fast. Doesn't seem to be any solution to this.

[jehutting]

@di512
If you still have problems with omxplayer playing the files too fast, could you run omxplayer with the -g option, and post the omxplayer.log?
Looking at E3V3A issue, I found a small problem with omxplayer. With your log I want to verify if that is also causing your issue.
Thanks in advance.

[E3V3A]

@di512
If you still have problems with omxplayer playing the files too fast, could you run omxplayer with the -g option, and post the omxplayer.log?
Looking at E3V3A issue, I found a small problem with omxplayer. With your log I want to verify if that is also causing your issue.
Thanks in advance.

Thank you!
I posted an issue in their github repo, and it was fixed by you. Unfortunately it seem to be an abandoned project as no PRs has been merged in a long time, and the only ones responding to issues are non-affiliated (?) people like yourself. It seem that they are trying to put omxplayer to rest, which is too bad, since it works very well for everything else.