search for: error_callback

...Modified: /trunk/source/mxn.google.geocoder.js ======================================= --- /trunk/source/mxn.google.geocoder.js Wed May 19 16:33:35 2010 +++ /trunk/source/mxn.google.geocoder.js Fri May 21 11:57:43 2010 @@ -28,7 +28,7 @@ this.callback = callback; this.geocoders = {}; if(error_callback === null) { - this.error_callback = this.geocode_error + this.error_callback = this.geocode_error; } else { this.error_callback = error_callback; } @@ -67,7 +67,7 @@ default: alert(api + '' not supported by mapstraction-geocoder''); } -} +}; /** * Change...

...riteCallback" file_decoder.c:60: warning: no semicolon at end of struct or union file_decoder.c:61: warning: type defaults to `int' in declaration of `metadata_callback' file_decoder.c:61: warning: data definition has no type or storage class file_decoder.c:62: parse error before "error_callback" file_decoder.c:62: warning: type defaults to `int' in declaration of `error_callback' file_decoder.c:62: warning: data definition has no type or storage class file_decoder.c:67: parse error before '}' token file_decoder.c:67: warning: type defaults to `int' in declaration...

...orking fine between java and libFLAC.so. Callback are called, C API is smart with void* client_data parameter, which is useful to keep custom structure. My problem is : with JNA and libFLAC, I can't identify if error callback has been called, due to variable visibility restriction, because error_callback implementation in java cannot communicate with java main code (not without an ugly trick). With native implementaiton of FLAC (decoder.c or other samples), client_data sent to FLAC__stream_decoder_init_file is updated by error_callback. But java keep initial reference of this parameter and java...

...ns one. But the decoder API does not seem setup for this type of synchronous operation. When a packet arrives, I'm trying to call process_single_frame and then supply the packet data in the read_callback. It takes the data but always calls the read_callback again for more data. It does call error_callback (status == 0) once, but never write_callback. So, I'm guessing that the packet does not have enough data for a frame. So, I tried queueing write_callbacks at the encoder before packetizing it and sending it. It seems like encoder init causes three write_callbacks that make up the metadata, a...

...e audio is silence, so I believe there is a high compression ratio ((4096 x 5) + metadata) -> 146 bytes decoder: [29.009735] HandleChanDataMsg, start: 1 [29.009773] SetAudioTimer, total: 1200, holdoff: 585 <process_single_frame called here> [29.009792] read_callback, size: 146 [29.009809] error_callback, status: 0 [29.009821] read_callback, size: 146 [29.009834] read_callback, size: 146 [29.009844] read_callback, size: 146 [29.009855] read_callback, size: 146 ... <calls read_callback forever> I can send out some of the code fragments if needed. Thanks, Chris On Tue, Dec 12, 2017 at 4:44 P...

...onst FLAC__int32 * const buffer[]) override { std::cout << "write_callback called!" << std::endl; abort(); return FLAC__StreamDecoderWriteStatus::FLAC__STREAM_DECODER_WRITE_STATUS_CONTINUE; } virtual void error_callback(::FLAC__StreamDecoderErrorStatus status) override {} } decoder; decoder.init("sample.flac"); decoder.process_until_end_of_metadata(); decoder.seek_absolute(1); return 0; } Despite not calling `process_single`, this snippet crashes with "...

...t; > But the decoder API does not seem setup for this type of synchronous operation. When a packet arrives, I'm trying to call process_single_frame and then supply the packet data in the read_callback. It takes the data but always calls the read_callback again for more data. It does call error_callback (status == 0) once, but never write_callback. So, I'm guessing that the packet does not have enough data for a frame. > > So, I tried queueing write_callbacks at the encoder before packetizing it and sending it. It seems like encoder init causes three write_callbacks that make up the m...

...+ if (!vq) { + err = -ENOMEM; + goto error_new_virtqueue; + } + + /* Setup virtqueue callback */ + cb.callback = virtio_mdev_virtqueue_cb; + cb.private = info; + err = parent->ops->ioctl(mdev, VIRTIO_MDEV_SET_VQ_CALLBACK, + (unsigned long)&cb); + if (err) { + err = -EINVAL; + goto error_callback; + } + + virtio_mdev_writel(vm_dev->mdev, VIRTIO_MDEV_QUEUE_NUM, + virtqueue_get_vring_size(vq)); + addr = virtqueue_get_desc_addr(vq); + virtio_mdev_writel(vm_dev->mdev, VIRTIO_MDEV_QUEUE_DESC_LOW, (u32)addr); + virtio_mdev_writel(vm_dev->mdev, VIRTIO_MDEV_QUEUE_DESC_HIGH, + (u3...

...irtqueue; > + } > + > + /* Setup virtqueue callback */ > + cb.callback = virtio_mdev_virtqueue_cb; > + cb.private = info; > + err = parent->ops->ioctl(mdev, VIRTIO_MDEV_SET_VQ_CALLBACK, > + (unsigned long)&cb); > + if (err) { > + err = -EINVAL; > + goto error_callback; > + } > + > + virtio_mdev_writel(vm_dev->mdev, VIRTIO_MDEV_QUEUE_NUM, > + virtqueue_get_vring_size(vq)); > + addr = virtqueue_get_desc_addr(vq); > + virtio_mdev_writel(vm_dev->mdev, VIRTIO_MDEV_QUEUE_DESC_LOW, (u32)addr); > + virtio_mdev_writel(vm_dev->mdev, VIRT...

...irtqueue; > + } > + > + /* Setup virtqueue callback */ > + cb.callback = virtio_mdev_virtqueue_cb; > + cb.private = info; > + err = parent->ops->ioctl(mdev, VIRTIO_MDEV_SET_VQ_CALLBACK, > + (unsigned long)&cb); > + if (err) { > + err = -EINVAL; > + goto error_callback; > + } > + > + virtio_mdev_writel(vm_dev->mdev, VIRTIO_MDEV_QUEUE_NUM, > + virtqueue_get_vring_size(vq)); > + addr = virtqueue_get_desc_addr(vq); > + virtio_mdev_writel(vm_dev->mdev, VIRTIO_MDEV_QUEUE_DESC_LOW, (u32)addr); > + virtio_mdev_writel(vm_dev->mdev, VIRT...

I refer to a problem that appeared on the flac list last August that was either solved off-list or abandoned. (http://lists.xiph.org/pipermail/flac/2005-August/000468.html) The problem is with using the C++ encoder classes, particularly the FLAC::Encoder::File:set_metadata function. JC said that the developers version of how to add a simple metadata block looked right, but it did not work for

Hi all: There are hardware that can do virtio datapath offloading while having its own control path. This path tries to implement a mdev based unified API to support using kernel virtio driver to drive those devices. This is done by introducing a new mdev transport for virtio (virtio_mdev) and register itself as a new kind of mdev driver. Then it provides a unified way for kernel virtio driver to