Closed yousefamar closed 5 years ago
There is actually a reason! I actually didn't implement the alsa part and the feature was from a great pull request. However, later on I was trying to fix something and I accidentally overwrote the newer audio.c
file.
There are a number of possible fixes. If you can compile the source code, overwrite audio.c
with this file and then make everything. This method should give the best performance.
Alternatively, you can use player_select = 3
and modify this line:
https://github.com/homeworkc/lazycast/blob/db425d30a868b752c16e9e3dcd5ec3439a5c6db8/d2.py#L197
to
os.system('omxplayer rtp://0.0.0.0:1028 -o alsa --live &')
If you choose this method and if you use a Windows 10 source, play something while connecting to PI. The reason is, omxplayer tries to automatically determine the audio format but Windows 10 doesn't send any audio stream if you don't play any sound (and then omxplayer will just give up). The original -n -1
argument forces omxplayer to ignore the audio track completely.
Thanks! Replacing audio.c
and recompiling worked flawlessly! I've spotted the third option for player_select
before too, but I avoid omxplayer streaming (inside and outside of lazycast) because it gives me terrible latency.
Would you like me to PR with the updated audio.c
if that's newer? Otherwise please feel free to close this issue.
Yeah. A PR sounds good.
First off, I just wanted to say thanks for your work on this amazing project!
As far as I can tell, the option for using alsa as sound output (presumably the default device) is ignored and treated as HDMI for the
player
player (see here), while it's supported forh264
(see here). Is there a reason for this?At the moment, I'm trying to get USB audio working (I'm running on a Pi Zero W, so I don't have an analogue input, instead USB to analogue) but even with
h264
it ends up going through HDMI anyway, so I wanted to tryplayer
. FWIW, a command likeomxplayer -o alsa test.mp4
works just fine.Any info much appreciated!