lca2013 – Day 3 – Session 2

Droids that talk: Pairing Codec2 and Android by Joel Stanley

Sophisticated DSP and SDR are within the reach of the LCA attendee skill see

FOSS Speech Codecs

  • Post to any platform
  • Possibilities

Digital Voice over Radio

  • Naarrow bandwidth
  • Low bitrate
  • Carried by VHF, HF
  • Not GSM or VOIP
  • 1000 times more efficient than voice over WIFI
  • 1/3 of bandwidth used by commercial Am Radio

Software Radio

  • Software and be free
  • CPU cycles can be nearly free

How Radio works?

  • Antenna
  • Pre-Amp – boast signal
  • Mixer – Takes pre-amp signal  + local oscillator signal
  • Another Audio Amplifier

FreeDV on Andriod

  • libusb-andriod
    • No lsoc support on Andriod
    • Integrates with Andriod permission framework
  • fdmdv2 and codec2
    • Worked as-is from freeDV
  • JNI Layer
    • Thread USB callback
  • Audio Playback
    • Uses Audiotrack API
  • Graphing hard- used GraphView
  • Canvas class for drawing scatter plot
  • Future – Waterfall plot



The future of non-volatile memory by Matthew Wilcox

NVM Express Standard

  • Talking to NVM across the PCIe bus
  • Various vendor standards
  • Want to have one driver, be able to switch between vendors easily

PCIe Drives

  • 2.5 and 3.5 Inc drives
  • A common slot for SA / SATA / PCIe
  • Support up to 4 lanes at 8Gb/s

Post-NAND Era

  • Various technologies in dev to replace NAND
  • Ferroelectric, Magnetoresistive, Phase-change, Racetrack
  • Most promise DRAM-comparable speeds
  • Only last a short time, not days/weeks of persistence with no power
  • CPU will treat these the way it treats DRAM – just loads and stores to it directly, no API

Programming Model

  • What if you allocate persistent memory?
  • malloc() is the wrong model
    • CPU is not persistent, after reset out of sync with memory
  • Block device also wrong model
  • POSIX provides open(), mmap()
  • So maybe a filesystem then?
    • Must bypass page cache
    • May be a simpler filesystem, not fully-featured, no page cache etc
    • Keith Packard has already done this for graphics memory
    • But writing files systems is hard, long time to get them stable

Linux Assumes page cache

  • O_DIRECT and splice() are good examples. May be other corner cases

Linux really sucks at sync

  • msync(MS_ASYNC) is a no-op
  • msync(MS_SYNC) is an inefficient way of calling fsync()
  • fsync() synchronises more than we need
  • So does fdatasync()
  • sync_file_range() doesn’t sync enough

Humans suck at sync

  • tdb has contained some horrendous races and missing syncs
  • If we expect normal human programmers to get it right we have to come up with something easy


  • CPU A modifies a cacheline and starts syncing it to the persistent memory
  • CPU B reads the same cacheline and observes CPU A’s Changes
  • Machine loses power. On reboot are we guaranteed that CPU A’s changes are still visable?
  • Difference between coherence and persistence
  • Journalling is HARD


  • Current API insulates us
  • Memory can become corrupted, as long as we crash before it hits storage, the corruption will never be observed

Improving error logs

  • Write directly to logs from inside the kernel
  • Snapshot kernel and state for recovery or debugging
  • Future machines may not have DRAM at all. What happens if you have  a problem, hard to cold boot
  • “Emails to 10TB system state to LKML” – Jeff Waugh
  • Cosmic rays corrupting memory while running