Difference between revisions of "LiveTranStack"

From Fixme.ch
Jump to: navigation, search
(Page creation)
 
(much more details)
Line 1: Line 1:
 
[[Category:Ongoing_Projects]]
 
[[Category:Ongoing_Projects]]
 
== Description ==
 
== Description ==
* Hardware / Software solution to enable live interpretation of talks
+
* Hardware / Software solution to enable live interpretation of talks, anywhere there's IP and power (we could use power banks as USB UPSs) ''Could be simplified as a simple IP intercom / duplex HW-SW stack''
  
 
== Goal ==
 
== Goal ==
 +
* At least two mic/headphones
 
* Cheap
 
* Cheap
 
* OSS / OSHW
 
* OSS / OSHW
Line 9: Line 10:
  
 
== Obstacles ==
 
== Obstacles ==
* Network and codec latency
+
* Network, software mixing and codec latency
 
* Mics getting ambient noise
 
* Mics getting ambient noise
  
== Component ==
+
== Components ==
* Raspberry pi (zero?)
+
* Raspberry pi or other GNU/Linux embedded system with USB, ethernet and GPIO
 
* pots, switches and LEDs
 
* pots, switches and LEDs
 
* USB mic-headphones
 
* USB mic-headphones
 
* OGG Opus
 
* OGG Opus
 +
* Power source
 +
* [2 line lcd?]
  
 +
== HW details ==
  
 +
We need a mute momentary switch. Also a buzzer (to diagnose start-up / majors problems)
 +
 +
All of what follows will be implemented twice par device (or plus).
 +
USB port for the audio devices, and a way to be sure which is which.
 +
Two (digital?) pots (mic and headphone gains)
 +
A enable/disable switch (with built-in led if cheap enough?)
 +
One LED to indicate if a mic is open (if not inside switch).
 +
 +
We map the digipots to alsa volume controls.
 +
 +
== SW details ==
 +
 +
Then, let's assume a GNU/Linux distro
 +
 +
 +
'''Setup:'''
 +
Parameters such as audio source (upstream) IP:port, also downstream IP:port and codec parameters are stored somewhere (sd)
 +
Also the language code of the stream (can we mux this somehow, or is it upstream's responsiblity)
 +
 +
Optionally drive a 2line led display and have enough buttons to set ip:ports and number of devices?
 +
 +
'''On boot:'''
 +
Enumerate USB devices. If one is absent, keep beeping its led. If both are absent, buzz till reset.
 +
If an upstream is set, attempt connection. If no connection, buzz / blink in another pattern.
 +
Software mix both sources and feed the output into an OGG Opus encoder. Stream this (UDP broadcast? or set ip:port)
 +
(Optionally mix upstream with lower level)
 +
 +
'''While true:'''
 +
while mute button is pressed:
 +
Cut USB inputs. Don't change upstream level.
 +
If no input is enabled, Upstream level = 1;
 +
If at least one input is enabled, Upstream < 1;
 +
On upstream failure: attempt reco (maybe double beep and blink)
 +
On downstream failure: same (maybe triple beep and blink)
 +
 +
 +
 +
== Roadmap ==
 +
* Test streaming a mono Opus to a raspi, look at usage, figure out a couple quality / latency settings.
 +
* Test encoding a mono Opus from a raspi, same.
 +
* Test doing the same with software mixing enabled (broadcasting a mix of the input stream and some local audio)
 +
* Test doing the same using an USB audio device as playback and capture at the same time.
 +
* Double it.
 +
* Figure out how to GPIO efficiently at the same time (implement buzzer and visual alerts)
 +
* Figure out how to control audio volumes via GPIO
 +
* Test the darn thing in a real setting
 +
* Monitor power use, derive estimation of battery-operation capacity
  
 
== Participants ==
 
== Participants ==
 
* [[User:Fzn]] (Leader)
 
* [[User:Fzn]] (Leader)

Revision as of 08:21, 26 January 2017

Description

  • Hardware / Software solution to enable live interpretation of talks, anywhere there's IP and power (we could use power banks as USB UPSs) Could be simplified as a simple IP intercom / duplex HW-SW stack

Goal

  • At least two mic/headphones
  • Cheap
  • OSS / OSHW
  • Qualitatively good

Obstacles

  • Network, software mixing and codec latency
  • Mics getting ambient noise

Components

  • Raspberry pi or other GNU/Linux embedded system with USB, ethernet and GPIO
  • pots, switches and LEDs
  • USB mic-headphones
  • OGG Opus
  • Power source
  • [2 line lcd?]

HW details

We need a mute momentary switch. Also a buzzer (to diagnose start-up / majors problems)

All of what follows will be implemented twice par device (or plus). USB port for the audio devices, and a way to be sure which is which. Two (digital?) pots (mic and headphone gains) A enable/disable switch (with built-in led if cheap enough?) One LED to indicate if a mic is open (if not inside switch).

We map the digipots to alsa volume controls.

SW details

Then, let's assume a GNU/Linux distro


Setup: Parameters such as audio source (upstream) IP:port, also downstream IP:port and codec parameters are stored somewhere (sd) Also the language code of the stream (can we mux this somehow, or is it upstream's responsiblity)

Optionally drive a 2line led display and have enough buttons to set ip:ports and number of devices?

On boot: Enumerate USB devices. If one is absent, keep beeping its led. If both are absent, buzz till reset. If an upstream is set, attempt connection. If no connection, buzz / blink in another pattern. Software mix both sources and feed the output into an OGG Opus encoder. Stream this (UDP broadcast? or set ip:port) (Optionally mix upstream with lower level)

While true: while mute button is pressed: Cut USB inputs. Don't change upstream level. If no input is enabled, Upstream level = 1; If at least one input is enabled, Upstream < 1; On upstream failure: attempt reco (maybe double beep and blink) On downstream failure: same (maybe triple beep and blink)


Roadmap

  • Test streaming a mono Opus to a raspi, look at usage, figure out a couple quality / latency settings.
  • Test encoding a mono Opus from a raspi, same.
  • Test doing the same with software mixing enabled (broadcasting a mix of the input stream and some local audio)
  • Test doing the same using an USB audio device as playback and capture at the same time.
  • Double it.
  • Figure out how to GPIO efficiently at the same time (implement buzzer and visual alerts)
  • Figure out how to control audio volumes via GPIO
  • Test the darn thing in a real setting
  • Monitor power use, derive estimation of battery-operation capacity

Participants