Java-Gaming.org Hi !
Featured games (91)
games approved by the League of Dukes
Games in Showcase (807)
Games in Android Showcase (239)
games submitted by our members
Games in WIP (872)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Microphone reader latency  (Read 830 times)
0 Members and 1 Guest are viewing this topic.
Offline philfrei
« Posted 2020-04-03 19:23:53 »

I was dabbling with using a TargetDataLine to get sound from a microphone and turn it around for real time use. It was a little tricky, but what I came up with has the TargetDataLine on one thread, and the SourceDataLine (for speaker output) on another thread.

On the mic input thread, a buffer is read from the TDL, converted to PCM and stored as an array in a ConcurrentLinkedQueue.

On the playback side, the buffers are polled from the queue on an as-needed basis, then the real-time effect can be applied here to the PCM, then the data converted back to audio bytes and shipped out via the SourceDataLine.

I'm playing around with various buffer sizes, especially the internal buffers for the TDL and SDL, but also the size of the reads and accompanying arrays stored in the ConcurrentLinkedQueue.

There are some strong audio coders that occasionally peruse this site. I'm wondering what you might think is a reasonable latency to aim for for a laptop. I'm using an i3 with 2.4GHz and 8GB RAM. The first experiments have left me with about 1/3rd of a second latency. Below that: dropouts become a problem.

It would be nice to cut it closer, but so far, the pacing of the two threads seem to be a little too variable to make any of the buffers smaller. My first attempt, putting both mic input and speaker output on the same thread, had worse dropouts. Both TDL and SDL employ blocking queues and these blocks work efficiently for the respective lines, but when ganged, each one's blocks also blocks the other. Working concurrently (putting each line in its own thread) seemed to be a big step in the right direction.

Pondering possible tests. Maybe monitoring how much the concurrent queue varies in length with the different buffer sizes would be a good objective measure to use for testing...hmm.

music and music apps: http://adonax.com
Pages: [1]
  ignore  |  Print  
 
 

 
Riven (843 views)
2019-09-04 15:33:17

hadezbladez (5778 views)
2018-11-16 13:46:03

hadezbladez (2597 views)
2018-11-16 13:41:33

hadezbladez (6195 views)
2018-11-16 13:35:35

hadezbladez (1494 views)
2018-11-16 13:32:03

EgonOlsen (4729 views)
2018-06-10 19:43:48

EgonOlsen (5779 views)
2018-06-10 19:43:44

EgonOlsen (3270 views)
2018-06-10 19:43:20

DesertCoockie (4171 views)
2018-05-13 18:23:11

nelsongames (5481 views)
2018-04-24 18:15:36
A NON-ideal modular configuration for Eclipse with JavaFX
by philfrei
2019-12-19 19:35:12

Java Gaming Resources
by philfrei
2019-05-14 16:15:13

Deployment and Packaging
by philfrei
2019-05-08 15:15:36

Deployment and Packaging
by philfrei
2019-05-08 15:13:34

Deployment and Packaging
by philfrei
2019-02-17 20:25:53

Deployment and Packaging
by mudlee
2018-08-22 18:09:50

Java Gaming Resources
by gouessej
2018-08-22 08:19:41

Deployment and Packaging
by gouessej
2018-08-22 08:04:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!