similar to: OggPCM2 : Channel Conversion Header

Jean-Marc Valin wrote: >>I'm also not entirely sure that the coding chosen for the channel >>definitions is the best one. Typically we'd expect each type of channel >>map to contain all and nothing but the channel definitions typically >>used with that map type, in some order. For example L, C, R, Ls, Rs and >>LFE for 5.1. If so, all we're really

On 2005-11-19, Jean-Marc Valin wrote: > Not sure this is a good idea. Remember that channel_map is just an > array (unless you want to make it a map?). So if you had a > OGG_CHANNEL_SPECIAL with an id of 1000, it would force 1000 entries in > the array. True, but remember that the channel map type implied the number of entries in the table, and also that in this organization

>> True, but remember that the channel map type implied the number of >> entries in the table, and also that in this organization you'll always >> number the logical channels consequtively since each logical channel >> indeed corresponds to an index into the array. If the channel map type >> says it's a map for 5.1, there will only be 6 slots in the table no

On 2005-11-17, Erik de Castro Lopo wrote: > I did flesh out the wiki a **little** more. Is the intent clearer now? Yes. Channel map type tells us what the primary interpretation of the stored signals is. Channel definitions are there to tell which stored channel corresponds to which abstract channel in the type. Channel conversions define downmixes to secondary formats, as they do in MLP,

> Yes. Channel map type tells us what the primary interpretation of the > stored signals is. Channel definitions are there to tell which stored > channel corresponds to which abstract channel in the type. Channel > conversions define downmixes to secondary formats, as they do in MLP, > and might end up being ignored unlike the channel map. I think the channel conversion will

> I that this is handled pretty nicely by the "simple map" that Sampo > suggested. This is basically the same thing as the "channel map" > described on the wiki, but with the (physical,logical) channel pair > swapped. So, using the syntax from the wiki: > channel_type = OGG_CHANNEL_MAP_STEREO > channel_map [OGG_CHANNEL_FRONT_LEFT] = 1 > channel_map

> True, but remember that the channel map type implied the number of > entries in the table, and also that in this organization you'll always > number the logical channels consequtively since each logical channel > indeed corresponds to an index into the array. If the channel map type > says it's a map for 5.1, there will only be 6 slots in the table no > matter how

Hi, I also think that outside of the extra headers, OggPCM2 is ready to be implemented. I suggest we make the main part (no extra headers) "officiel" now. We could always add stuff later on by bumping the minor number if really needed. If we go this way, I also suggest we rename it to OggPCM just to make sure it doesn't get confusing with the original OggPCM. Does anyone see a good

Hi, although the OggPCM2 draft states that it is a work in progress, it also states that the main points of contention are in optional headers. I'd like to add OggPCM2 seeking support to liboggz, which will also display correct timestamps in oggzdump and allow oggz-validate to run on OggPCM2 files for testing, while implementations are being developed. In order to do this, only the Main

Hi, I'd support the view of freezing the main header, since it helps in actually getting some implementation happening and it seems fully agreed on by everyone. FAIK, Zen has already started an implementation and if you, Conrad, implement, too, there is enough code to do validation. What do you expect now to make it an "officially frozen" specification? Publish it on the main

On 11/15/05, Erik de Castro Lopo <mle+xiph@mega-nerd.com> wrote: > Hi all, > > The remaining issue to be decided for the OggPCM2 spec is the support > of chunked vs interleaved data. I think interleaved is the obvious choice - that's what most audio applications are used to dealing with, it's what we need to feed to audio hardware in the end usually, etc. Whilst I

Rene Herman wrote: > Why store N-bit in the most significant bits and not least? Doesn't > that mean an application would likely need to shift everything down > again? One advantage of storing in the MSB's is that the relative value remains correct when processed as the larger word size. For instance, a signed 12 bit integer would use 0x400 to represent +50% amplitude. By

> One obvious thing that seems to be lacking is the granulepos mapping. As > suggested in Ogg documentation, for audio a simple sampling frame number > ought to suffice, but I think the convention should still be spelled > out. I was under the (maybe wrong) impression that the Ogg spec already covered everything that's needed for granulepos. If that's not the case, please

Hi all, The remaining issue to be decided for the OggPCM2 spec is the support of chunked vs interleaved data. Just so that everyone understands what we are talking about, consider a stereo file that gets stored as an OggPCM file. Within an OggPCM packet, the audio samples for the left and right channels can be stored as interleaved where the samples would be: l0, r0, l1, r1, ..... lN, rN

Michael Smith wrote: >Whilst I accept that there are many good uses for chunked data, I >think the transformation is trivial, particularly given certain >characteristics of the Ogg container. Remember, the data, if you read >an ogg stream into memory, is _already_ likely to be non-contiguous, >due to ogg's structure. It's trivial, and has insignificant additional

On 2005-11-16, Jean-Marc Valin wrote: > Otherwise, what do you feel should be changed? One obvious thing that seems to be lacking is the granulepos mapping. As suggested in Ogg documentation, for audio a simple sampling frame number ought to suffice, but I think the convention should still be spelled out. Secondly, I'd like to see the channel map fleshed out in more detail. (Beware

Sampo Syreeni wrote: > Secondly, I'd like to see the channel map fleshed out in more detail. Sampo, I did flesh out the wiki a **little** more. Is the intent clearer now? > (Beware of the pet peeve...) What is that pet peeve? > IMO the mapping should cover at least the > channel assignments possible in WAVE files, the most common Ambisonic > ones, and perhaps some added

I made a few updates to OggPCM2 http://wiki.xiph.org/index.php/OggPCM2 reflecting the latest discussions. Could everyone have a look at it and see if they agree. Otherwise, what do you feel should be changed? Anyone wants to speak in support of chunked PCM? For all those that are just tired of this mess like me, please express yourself in the new spec I created: OggPCM3

On Tue, Feb 28, 2023 at 07:04:33PM +0000, Bobby Eshleman wrote: > Add support for sockmap to vsock. > > We're testing usage of vsock as a way to redirect guest-local UDS > requests to the host and this patch series greatly improves the > performance of such a setup. > > Compared to copying packets via userspace, this improves throughput by > 121% in basic testing.

On Tue, Aug 01, 2023 at 04:30:22AM +0000, Bobby Eshleman wrote: >On Thu, Jul 27, 2023 at 09:48:21AM +0200, Stefano Garzarella wrote: >> On Wed, Jul 26, 2023 at 02:38:08PM -0400, Michael S. Tsirkin wrote: >> > On Wed, Jul 19, 2023 at 12:50:14AM +0000, Bobby Eshleman wrote: >> > > This commit adds a feature bit for virtio vsock to support datagrams. >> > >