Av:Developer:Songcast:Ohm - Revision history

Simonc at 14:42, 19 August 2015

2015-08-19T14:42:52Z

2014-03-27T15:43:27Z

OHM NULL URI

← Older revision		Revision as of 15:43, 27 March 2014
Line 296:		Line 296:

	=== OHM NULL URI ===		=== OHM NULL URI ===
-	The URI ohm://0.0.0.0:0 is the OHM NULL URI.	+	The URI <tt>ohm://0.0.0.0:0</tt> is the OHM NULL URI.

	If requested to play this URI, a Receiver should clear any Track Uri, Track Metadata, and Track Metatext, and be silent.		If requested to play this URI, a Receiver should clear any Track Uri, Track Metadata, and Track Metatext, and be silent.

2013-12-09T13:53:18Z

Message Format

← Older revision		Revision as of 13:53, 9 December 2013
Line 130:		Line 130:
	\| 4		\| 4
	\| MediaLatency		\| MediaLatency
-	\| The duration of the audio buffer	+	\| The duration of the Sender's audio buffer
	\|-		\|-
	\| 4		\| 4
	\| MediaTimestamp		\| MediaTimestamp
-	\| The time when this frame was placed into ~~the~~ audio buffer {if the timestamped flag is on)	+	\| The time when this frame was placed into an audio buffer of duration <tt>MediaLatency</tt> on the Sender (if the timestamped flag is on)
	\|-		\|-
	\| 8		\| 8
Line 232:		Line 232:
	\| The list of slave endpoints, where s = 6 * SlaveCount		\| The list of slave endpoints, where s = 6 * SlaveCount
	\|}		\|}
-

	=== Control Messages ===		=== Control Messages ===

2013-11-06T11:49:33Z

← Older revision		Revision as of 11:49, 6 November 2013
Line 232:		Line 232:
	\| The list of slave endpoints, where s = 6 * SlaveCount		\| The list of slave endpoints, where s = 6 * SlaveCount
	\|}		\|}
		+

	=== Control Messages ===		=== Control Messages ===

2013-11-06T11:46:20Z

Nasty workaround for white text on white background bugs

← Older revision		Revision as of 11:46, 6 November 2013
Line 20:		Line 20:
	! Description		! Description
	\|- align="left" style="color:#ffffff; background-color:#008833;"		\|- align="left" style="color:#ffffff; background-color:#008833;"
-	~~! colspan="3"~~ \| Header	+	\| Header
		+	\|
		+	\|
	\|-		\|-
	\| 4		\| 4
Line 74:		Line 76:
	\| 16392		\| 16392
	\|- align="left" style="color:#ffffff; background-color:#008833;"		\|- align="left" style="color:#ffffff; background-color:#008833;"
-	~~! colspan="3"~~ \| Audio	+	\| Audio
		+	\|
		+	\|
	\|-		\|-
	\| 1		\| 1
Line 176:		Line 180:
	\| Pcm samples, where n = Channels * BitDepth * SampleCount / 8		\| Pcm samples, where n = Channels * BitDepth * SampleCount / 8
	\|- align="left" style="color:#ffffff; background-color:#008833;"		\|- align="left" style="color:#ffffff; background-color:#008833;"
-	~~! colspan="3"~~ \| Track	+	\| Track
		+	\|
		+	\|
	\|-		\|-
	\| 4		\| 4
Line 198:		Line 204:
	\| The track metadata in DIDL-Lite format, where q = TrackMetadataLength		\| The track metadata in DIDL-Lite format, where q = TrackMetadataLength
	\|- align="left" style="color:#ffffff; background-color:#008833;"		\|- align="left" style="color:#ffffff; background-color:#008833;"
-	~~! colspan="3"~~ \| Metatext	+	\| Metatext
		+	\|
		+	\|
	\|-		\|-
	\| 4		\| 4
Line 212:		Line 220:
	\| The metatext in DIDL-Lite format, where r = MetatextLength		\| The metatext in DIDL-Lite format, where r = MetatextLength
	\|- align="left" style="color:#ffffff; background-color:#008833;"		\|- align="left" style="color:#ffffff; background-color:#008833;"
-	~~! colspan="3"~~ \| Slave	+	\| Slave
		+	\|
		+	\|
	\|-		\|-
	\| 4		\| 4

2011-09-01T16:06:25Z

Message Format

← Older revision		Revision as of 16:06, 1 September 2011
Line 126:		Line 126:
	\| 4		\| 4
	\| MediaLatency		\| MediaLatency
-	\| The ~~length in milliseconds~~ of the audio buffer	+	\| The duration of the audio buffer
	\|-		\|-
	\| 4		\| 4

2011-09-01T16:05:37Z

Timestamps

← Older revision		Revision as of 16:05, 1 September 2011
Line 238:		Line 238:

	=== Timestamps ===		=== Timestamps ===
-	Accurate timestamps allow appropriately equipped Songcast Receivers to achieve close audio synchronisation. But timestamps should only be used when high accuracy is achievable. ~~Timestamps~~ are ~~made~~ according to an audio MCLK that is 256 * 44K1, or 256 * 48K.	+	Accurate timestamps allow appropriately equipped Songcast Receivers to achieve close audio synchronisation. But timestamps should only be used when high accuracy is achievable. The timestamps and the media latency are measured according to an audio MCLK that is 256 * 44K1, or 256 * 48K.

	=== Track Messages ===		=== Track Messages ===

2011-05-10T10:42:33Z

OHM NULL URI

← Older revision		Revision as of 10:42, 10 May 2011
Line 286:		Line 286:

	=== OHM NULL URI ===		=== OHM NULL URI ===
-	The URI ohm:0.0.0.0:0 is the OHM NULL URI.	+	The URI ohm://0.0.0.0:0 is the OHM NULL URI.

	If requested to play this URI, a Receiver should clear any Track Uri, Track Metadata, and Track Metatext, and be silent.		If requested to play this URI, a Receiver should clear any Track Uri, Track Metadata, and Track Metatext, and be silent.

2011-05-10T10:42:23Z

OHM Sender Channel

← Older revision		Revision as of 10:42, 10 May 2011
Line 284:		Line 284:

	A Receiver engages with an Multicast Sender by exchanging messages with the Multicast endpoint indicated by this OHM URI.		A Receiver engages with an Multicast Sender by exchanging messages with the Multicast endpoint indicated by this OHM URI.
		+
		+	=== OHM NULL URI ===
		+	The URI ohm:0.0.0.0:0 is the OHM NULL URI.
		+
		+	If requested to play this URI, a Receiver should clear any Track Uri, Track Metadata, and Track Metatext, and be silent.

	=== OHM Control ===		=== OHM Control ===

2011-05-10T09:49:26Z

OHM Control

← Older revision		Revision as of 09:49, 10 May 2011
Line 289:		Line 289:
	In general a Receiver is required to send a Join message to the Sender when it starts listening and a Listen message every second or so after that. However, when using Multicast UDP it is not necessary for a Receiver to send a Listen message if it has detected that some other Receiver has already sent one. This is because the only purpose of the Listen message is to ensure that the Sender continues sending Audio messages, and any Listen message from any Receiver will serve this purpose.		In general a Receiver is required to send a Join message to the Sender when it starts listening and a Listen message every second or so after that. However, when using Multicast UDP it is not necessary for a Receiver to send a Listen message if it has detected that some other Receiver has already sent one. This is because the only purpose of the Listen message is to ensure that the Sender continues sending Audio messages, and any Listen message from any Receiver will serve this purpose.

-	A Multicast ~~OHM~~ Sender and a listening Receiver implement the following state machines to reduce unnecessary Multicast network traffic.	+	A Multicast Sender and a listening Receiver implement the following state machines to reduce unnecessary Multicast network traffic.

	[[File:Songcast Sender Multicast State Transition Diagram.png]]		[[File:Songcast Sender Multicast State Transition Diagram.png]]