From: Jonathan W. <jw...@ph...> - 2008-01-16 22:35:05
|
Hi Pieter > > I should note that apart from the packets containing zero audio data these > > zeroed packets should in every other respect be valid audio packets - in > > particular the sample timestamps sent to the device must be right. > > It should be possible to do so, since we can re-use the normal packet > header generation, but simply use a 'empty payload' data generation > function when doing shutdown. That would be the easiest thing to > implement. I'll try to implement it over the next few days. I shall await it with interest and revisit the shutdown issues when it appears. FYI, the way I used to implement this (before the latest streaming changes) was to have a shutdown flag set in the stream processor when shutdown was in progress. After reading from the ports as normal (to prevent buffer overflows) the standard packet generator checked for this flag and if it were set just did a memset() on the packet to set all the data to zero. We also have to clarify terminology so I don't get confused. To me, a normal packet is one which contains actual audio data. An empty packet is an iso packet which contains just the header with no audio data at all. A silence packet is a normal audio data packet but with all the audio data set to zero. That's how I would interpret the three types of packets we seem to have at the moment (although as previously mentioned there may not be a practical difference between empty and silence currently). I'm not fussed if we change the terminology but either way I'd like to know what each of these terms really refers to. If we use the above terminology I think "'empty payload' data generation function" mentioned above should really be "'silence payload' data generation function" unless of course you are referring to later in the shutdown process. Regards jonathan |