News:

Server migration complete, Welcome to version 2.1.1

+-+-

+-User

Welcome, Guest.
Please login or register.
 
 
 
Forgot your password?

+-Site Stats

Members
Total Members: 16398
Latest: rafelog927
New This Month: 0
New This Week: 0
New Today: 0
Stats
Total Posts: 132035
Total Topics: 16363
Most Online Today: 95
Most Online Ever: 7634
(January 21, 2020, 02:14:03 AM)
Users Online
Members: 1
Guests: 72
Total: 73

Remote Player Audio Playback

Started by james-s, October 02, 2023, 06:48:44 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

james-s

What would cause broken or crackling playback through a Soundblaster3 connected to USB on a RPi Falcon Pi-Cap as a remote FPP player?  When connected to the standalone FPP player, no issues that I can tell. Just when I connect it to the remote player when audio degradation occurs.  Same audio file loaded to both.

Last year, the remote Pi-Cap was my only controller and I start only with an outdoor speaker.   This year going to jump into FM transmitter and hoping to use this Pi-Cap to connect to the transmitter. Maybe not doable but that's why I am here asking.  ;)

Player:
RPi 4B 4 GB
FPP 7.1
No Controller

Remote:
RPi 4B 2 GB
FPP 7.1
Falcon Pi-Cap

MikeKrebs

 IIRC, I thought there have been issues with using remotes as sound sources. It is just memory of some questions on one of these forums but I did think that was a problem. So don't quote me but it is easy to fix if that is true.

As an experiment, change the roles of the two RPis.

breese

Do you currently have the remote near the transmitter?
Some transmitters have been known to interfere with the soundblaster.
Separate them by 10' and it should clear things up.

algerdes

The reason that using a remote to feed audio isn't too trustworthy is the "catch up/slow down" of the remote to stay in sync with the master unit.  Remotes will speed up if they are behind the master or slow down if they are ahead.

In testing, we found it to be visually negligible but audio wise it was quite noticeable.

With the updates and all (since we tried it) this may or may not still be the case.
Sequencers: Vixen3 and xLights
Players: FPP and xSchedule Controllers:  Renards - SS24/SS16; E1.31 - San Devices E682 - Falcon F16, F4, F48 - J1Sys - DIYLEDExpress E1.31 Bridges.  Much more!

james-s

Quote from: breese on October 03, 2023, 04:16:46 AMDo you currently have the remote near the transmitter?
Some transmitters have been known to interfere with the soundblaster.
Separate them by 10' and it should clear things up.


Not using a transmitter just yet.  Just hooking up aux to a speaker for testing.  But will keep the 10' rule in mind when doing FM transmission.   Probably going to start with one of the small fm transmission boards before investing in boxed typed.

james-s

Quote from: algerdes on October 03, 2023, 07:35:03 AMThe reason that using a remote to feed audio isn't too trustworthy is the "catch up/slow down" of the remote to stay in sync with the master unit.  Remotes will speed up if they are behind the master or slow down if they are ahead.

In testing, we found it to be visually negligible but audio wise it was quite noticeable.

With the updates and all (since we tried it) this may or may not still be the case.

This make sense on remotes catching up or slowing down.   Maybe will need to run sound off the main show player but I was hoping to keep it in my house.  I would try putting a transmission wire inside but the wife won't let that happen.  ;D

james-s

#6
Quote from: MikeKrebs on October 02, 2023, 08:28:51 PMIIRC, I thought there have been issues with using remotes as sound sources. It is just memory of some questions on one of these forums but I did think that was a problem. So don't quote me but it is easy to fix if that is true.

As an experiment, change the roles of the two RPis.
Just found time to switch the player/remote roles on the two and the sound quality is the same from the Sound Blaster 3 to speaker connection as standalone.    I am not how much memory the RPi with the bad sound but I know it is a 4 B+.   May be only 2BM.   I do know the one that doesn't have the sound issue is a RPi 4B+ has 4 MB.    Could the issue be running a Falcon Pi-Cap on the one that has the bad sound?  Maybe asking too much of the processor?

james-s

Update:  

  • Switched out the remote player Pi with an RPi 4B with 4MB - bad audio.
  • Took off the Falcon Pi-Cap (Disabled Pi-Hat in the output configuration) - bad audio.

I cannot find any configuration where audio plays cleanly on a remote.  Not sure where to go from here other than rethinking where I can put the show player running as the conductor outside where I can place an outdoor speaker and  eventually a FM transmitter.  Maybe one of the developers will see this thread and/or try the Zoom Room.



dkulp

You could try turning on the "Ignore Media Sync Packets" setting (advanced mode UI, audio/video tab).   It may drift slightly from master though.  Not sure if it would be noticible. 

If the remote is wifi, you could also try changing from multicast for the sync packets to unicast.   Many low end access points handle. multicast rather poorly which can cause them to come at strange times affecting the audio. 

Daniel Kulp - https://kulplights.com

tetleytealeaf

Related, but I recently created another thread related to audio off of FPP remote.   I am simply not having any sync problems and am perfectly happy with it.   

My problem is, the scheduler won't seem to set the volume on the remote.  I can manually set the volume on the remote and it seems scheduling works fine when it's on the FPP master, but scheduling on the remote is getting ignored.  So I'm having to switch back a perfectly good audio off the remote and move it back to the master.

james-s

Quote from: dkulp on October 03, 2023, 05:54:41 PMYou could try turning on the "Ignore Media Sync Packets" setting (advanced mode UI, audio/video tab).  It may drift slightly from master though.  Not sure if it would be noticible.

If the remote is wifi, you could also try changing from multicast for the sync packets to unicast.  Many low end access points handle. multicast rather poorly which can cause them to come at strange times affecting the audio.


@dkulp - I tried the "Ignore Media Sync Packets" and the audio did shift from the light sequencing.  

I noticed there is a setting that allows a remote +/- adjustment with the master which I take to allow for differences in potential differences for a remote versus another remote to keep them all in sync with the master.

As an enhancement, is it possible to allow a similar adjustment between audio and and the start of the sequencing playback?   Just thinking there may be scenarios like this where the audio is just not right in step with the sequencing during playback.  I can see where anything from networking, controller, FPP processor, speaker/fm transmission lag and who knows what can make a difference between what was sequenced in xLights versus what audio is heard.   This adjustment could start early or delay the playback of audio to when the pixel outputs begin by a +/- in microseconds.  Just an idea.  :)

Support FPP

+- Recent Topics

Kiosk mode touchscreen by Poporacer
February 19, 2024, 08:57:25 AM

reviving a bbb on an octoscroller by Poporacer
February 18, 2024, 11:25:33 AM

FPP After Hours Music Plugin has been updated by Poporacer
February 16, 2024, 03:40:05 PM

External WiFi Adapter and Antenna by JonB256
February 16, 2024, 08:25:13 AM

troubles getting UCS2904/TM1814 to work properly by ocupmoc
February 12, 2024, 11:15:53 AM

F16v4s keep freezing up by Zcarpenter
February 12, 2024, 08:02:46 AM

xLights in Ubuntu 22.04 by LedMutt
February 07, 2024, 08:48:43 PM

FPP 8 early alpha pre-release feedback by LedMutt
February 07, 2024, 08:39:23 PM

Why a custom/minimized bootstrap implementation in fpp? by jcross
February 07, 2024, 12:03:14 PM

AfterHours Plugin status from API or MQTT? by jcross
February 07, 2024, 10:12:32 AM

Powered by EzPortal
Powered by SMFPacks Menu Editor Mod